A new login provider is implemented to authenticate users agains an OAuth2 authorization service. The implementation should be done in a way so it behaves as a single-sign-on solution.
Note: this uses the same technology OAuth2 as facebook, google, twitter etc, however the goal of this issue is not to support those authentication mechanisms but integrate OpenOLAT in a known and specified IT infrastructure using a SSO mechanism based on OAuth2.
- User comes to OO login page
- This authentication request is automatic, user does not have to press a button to initiate authentication
- Authentication server does whatever is necessary to authenticate user (probably based on windows user ID) and return to OO
- OO asks the authentication server if everything is ok
- Usersession is authenticated and user redirected to page within OpenOLAT
- Necessary OAuth2 endpoint configurations
- Mapping table to map OAuth2 user data to OO user attributes, similar to LDAP
- Flag to allow/disallow user generation on-the-fly
- When enabled, some rules must exist to create the OO username. What happens when mandatory data fields are missing?
- When disabled, a dialog must tell user that his account has not yet been activated (e.g. not yet synced via DLAP or another syncher method)
Problems to solve
- How to login using the OLAT login provider? E.g. after OAuth2 workflow fails, the user is prompted with standard login provider?
- When creating users via LDAP, REST, File upload or manually, the OAUTH2 authentication mapping must somehow be created or some matching mechanism must be implemented (e.g. as with LDAP, based on username or email or something else)