ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Profile switching APIs breaking Single Sign-on for web access

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Profile switching APIs breaking Single Sign-on for web access

    We are having a problem with the combination of web access, Single Sign-on and profile switching that has us completely stumped.

    I apologise, I don't know how most of this works. I only work on the programs that use the profile switching facility. I don't even work on the code that calls the APIs themselves.


    Our users use Single Sign-on (kerberos principle), and access applications via web pages served directly from the iSeries. The first page they see is a menu listing the pages their user profile is allowed to access.
    Some of those pages use profile switching in order to be able to perform an action as profile QSYSOPR. They are switched back to their own user profile immediately afterwards.

    Recently, a bug has appeared where after the user uses one of these screens, next time they try and access the web interface their menu is empty because the iSeries is still seeing the user ID as QSYSOPR.
    It's like the switch back from QSYSOPR to their own user profile failed, and the error then persists across to their next login session so it's like it has corrupted the user's SSO setup in some way

    The issue only affects SSO users - Users who log in with a username and password are not affected. I don't know if the switch back from QSYSOPR fails or not for non-SSO users, but if it does fail then it does not persist to their next login session.
    SSO users have to be removed from SSO and re-added to restore their access.

    Additionally, we have so far failed to reproduce the error on the test box.

    This code has been in place for years and the issue has only just started, so our best guess is that an IBM PTF fixed a bug that our code was unknowingly depending on.


    The profile switching is accomplished as follows:

    1. use the QsyGetProfileHandle API to get the handle for their current user profile
    2. use the QsyGenPrfTkn and QsySetToPrfTkn APIs to switch to QSYSOPR and to return a token
    3. Do actions as QSYSOPR
    4. use the QsySetToProfileHandle API to switch back to the original user profile, using the handle from step 1
    5. use the QsyRemoveAllPrfTknsForUser API for QSYSOPR
    6. Use the QsyRemovePrfTkn API for the token returned in step 2



    Any help is appreciated.

  • #2
    I'm not sure why you're using 2 APIs that seem to do the same thing? I've not used the Profile Token APIs but looking at the knowledge centre, they seem to do the same job as the QsyGetProfileHandle and QsySetToProfileHandle APIs. Also, you haven't mentioned that you delete the profile handle afterward (only the profile token). There is a limit of 20,000 active profile handles per job though I'm not sure if that would cause the issue you have mentioned (it would affect all users, not just some unless the SSO ones use a different process).
    Swapping to the QSYSOPR ID is raising red flags with me as well. Why do you need to run jobs under the QSYSOPR user ID? If this is to access your data, you shouldn't be using system profiles for securing these as the system may run tasks under this ID. You should be using your own ID for this sort of thing. If it's for accessing some system functions, granting authority via group profiles might be a better solution, and it would mean using these profile switching APIs would be unnecessary.

    Comment


    • #3
      It has abruptly started working again despite no iSeries changes. But still, thanks for responding.

      I can't comment on the choice of APIs, another team wrote the utility program that does the API calls. I will mention the 20'000 handle limit and the option to delete the handles to that team.

      I haven't worked here long, and the choice to do so much under QSYSOPR seemed very strange to me too. I don't know enough about the actions done while swapped to QSYSOPR to comment on why it needed to be this way.

      Comment

      Working...
      X