[OPENAM-10296] Session UI only allows searching for users in datastore Created: 23/Dec/16  Updated: 29/Jul/19  Resolved: 22/May/18

Status: Resolved
Project: OpenAM
Component/s: session, XUI
Affects Version/s: 14.0.0, 14.0.0-M9, 14.1.0, 14.1.1, 14.5.0, 14.5.1, 5.5.1
Fix Version/s: 6.0.0.3, 6.5.0, 6.0.1, 5.5.2

Type: Bug Priority: Major
Reporter: Sam Drew Assignee: Julian Kigwana [X] (Inactive)
Resolution: Fixed Votes: 1
Labels: AME
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File ScreenShot-14.1.1-working-as-expected.png     PNG File ScreenShot-session-search-dialog-with-loading-icon.png    
Issue Links:
Duplicate
is duplicated by OPENAM-13222 Active sessions not appearing in AM c... Closed
Relates
relates to OPENAM-13222 Active sessions not appearing in AM c... Closed
relates to OPENAM-15080 unable to search and invalidate user ... Open
Target Version/s:
Rank: 1|hzsp4n:
Needs backport:
Yes
Support Ticket IDs:
Verified Version/s:
Needs QA verification:
Yes
Functional tests:
No
Are the reproduction steps defined?:
Yes and I used the same an in the description

 Description   

The sessions search feature within OpenAM requires a user to exist in the datastore in order to search for and delete a session. This means it will not be possible to find sessions for dynamic sessions, which do not make use of a user store.

To recreate

  • Log into OpenAM as amadmin
  • Create a new subrealm
  • Set up Social Authentication within the realm (this could be any feature which allows OpenAM to act as the equivalent of a Service Provider)
  • Navigate to Subrealm -> Authentication -> User Profile
  • Set value of User Profile to Ignored and Save
  • In a private browsing session log in to subrealm with social auth
  • As amadmin attempt to search for session in realm
    Expected
  • Possible to search for session with username Google-* (or whatever the session was issued as)
    Actual
  • Sessions list will only submit search for user existing in user store.


 Comments   
Comment by Nathalie Hoet [ 31/Jan/17 ]

Other scenario is if you do not have a datastore at all. Users can authenticate through LDAP for example, but none of their session can be searched.

Comment by Ivailo Kolev [ 02/May/18 ]

We upgraded to AM 5.5.1 and we are affected by this issues. Its fixing is important for us.  Which AM version is it planned to be fixed in? Will a patch be released for AM 5.5.1 after the fix?

Comment by Peter Major [X] (Inactive) [ 02/May/18 ]

Ivailo Kolev which use case applies to you? The REST endpoint for querying the sessions should work, my understanding is that only the UI has this limitation in place.

Comment by Ivailo Kolev [ 02/May/18 ]

The use case is that external users'(for example users from LDAP) sessions cannot be listed in the XUI.

Comment by Peter Major [X] (Inactive) [ 02/May/18 ]

And those external user stores aren't configured as data stores? Are you using ignored or dynamic profile mode?

Comment by Ivailo Kolev [ 02/May/18 ]

Yes, user stores are not configured as data stores. We are using the ignored profile.

Comment by Peter Major [X] (Inactive) [ 02/May/18 ]

In that case as a workaround you should be able to use the REST API directly.

Comment by Ivailo Kolev [ 02/May/18 ]

Thanks for the workaround. We know about it and we are using it. But it is a temporary solution that has some inconveniences. We need the sessions listing to be working in the XUI, too. The question is if the bug will be fixed and if so which release the fix is planned for.

Comment by Andy Hall [ 09/May/18 ]

Ivailo Kolev  Please raise a support ticket here.

Comment by Julian Kigwana [X] (Inactive) [ 16/May/18 ]

Currently, wildcards are not supported on that endpoint. An interim solution would be to allow the submission of known usernames, even if no match was found in the datastore.

Comment by Andy Hall [ 18/May/18 ]

Peter Major [X] does the REST api handle wildcards?

Comment by Peter Major [X] (Inactive) [ 18/May/18 ]

No, the backend only supports exact matches at the moment.

Comment by Ľubomír Mlích [ 29/Jul/19 ]

it works now, seems I was doing something wrong <- exact match only.

Generated at Mon Mar 01 04:09:19 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.