IdStory Identity Manager

OpenAM authentication module will consist of two main parts.

• Authentication filter in filter chain
• REST endpoint providing info about users privileges in OpenAM

First part is pretty straightforward and basically consists of creating OpenAMAuthenticationFilter and OpenAMAuthenticationManager classes and inserting them in spring's security filter chain. Actual OpenAM endpoint's URL will be stored in IdM's configuration.

Said REST endpoint will work as proxy between OpenAM and user and will basically provide access to identity attributes from OpenAM.

• Should this feature be part of core IdM or should it be developed as a separate module?
• Which configuration parameters will be needed? (Name of the cookie, OpenAM URL, domain for the cookie, which OpenAM identity's attributes will be exposed via IdM's REST endpoint)

Several questions and use-cases we discussed with Honza and Peter:

1) Users are authenticated with their login and password by OpenAM. Should they be assigned internal IdM authentication token - JWT token, or not? If yes, should the creation of IdmJwtAuthentication (setting of the granted authorities, auth expiration etc.) be done in the OpenAMAuthenticator?
- Yes, they should have JWT token, it's needed for correct handling of their grants in IdM
- Creation of IdmJwtAuthentication should be hidden, OpenAMAuthenticator shouldn't explicitly set auth expiration or grants, that should be set from core configuration. There should be some 'util' method in SecurityService, which will get basic information - what identity is authenticated, which module authenticates the user. This method will handle the rest. (Now the same code of creating IdmJwtAuthentication is in DefaultLoginService and DefaultAccAuthenticator, that should be refactored.)

• The OpenAmAuthenticationFilter can't commit error response every time, because then even login page wouldn't be loaded - this should be solved by #473
• What if user was authenticated by local IdM storage (e.g. it's an admin account which doesn't exist in OpenAM)? Such user would be always logged out by OpenAmAuthenticationFilter. But that's not what we want, we need local admins.

3) What if user 'localAdmin' has valid IdM session and at the same time he has valid OpenAM cookie, which corresponds to user 'openamTestUser'? Which user should be authenticated to IdM?

4) When user logs out of IdM, currently it only deletes his JWT token in fronted. What should happen fro users authenticated by OpenAM?
- We should delete OpenAM cookie (which can be done at fronted) and invalidate their session by OpenAM (by calling OpenAM REST /logout).
- If we don't invalidate their sessions, the token would be still valid, which is not really safe. Moreover we could hit the sessions limit in OpenAM (one user can have at most 5 active sessions).

• we don't need "SSO logout" for now - the IdM session will be valid as long as the user is active in IdM, even if the OpenAM token expired.
• the OpenAM authentication filter will be ordered after JWT authentication filter. So it will not be called for every request, which could decrease performance (checking token & creating JWT tokens). Still it will support SSO login (when users first get to IdM and have valid token, they will be logged in).

Footnote:
First point means that I don't need to solve JWT token invalidation at all. Yesterday I implemented it using IdmAuthorityChange change mechanism as Radek suggested, that worked well (only one little bug - #606), but I had problems determining if the user was authenticated by OpenAM, or core. (The problem was in SSO login - call to /remote-auth endpoint resulted to setting JWT token from core and the frontend "remembered" this token for the whole user session. So when the OpenAM token was expired, user's session still was not invalidated because the filter thought it was authenticated by core. Maybe loginAuthenticatedUser should set information about module from current authentication.)

Thank you. I changed the version of the module to 1.0.0-SNAPSHOT and version of core dependencies.