Differences

This shows you the differences between two versions of the page.

--- en:2.0:single_sign_on [2025/05/05 00:47] – [C. Configuring Admidio with the Service Provider] kainhofer
+++ en:2.0:single_sign_on [2025/05/09 00:21] (current) – kainhofer
@@ Line 19: / Line 19: @@
 |
-Other systems like Prestashop do not provide any freely available SAML plugin, only some very expensive commercial extensions.
+Other systems like Prestashop do not provide any freely available SAML or OpenID plugin, only some very expensive commercial extensions.
@@ Line 109: / Line 109: @@
 ==== Single-Sign-On with OpenID Connect using an external Identity Provider (IdP) ====
-OpenID Connect is based on exchanging data with JSON objects. Rather than working only with browser redirects like SAML, OpenID is based on OAuth and extensively uses direct communication ("backchannel") between the Relying Party and the IdP. Rather than documenting only a successful login, OpenID separates authentication (successfull login) and authorization (roles that grant user rights). It also does not rely on an active session at the IdP. Rather it generates a dedicated password (the "token") for the client and thus replaces the user's individual password with app-specific passwords, which are handled internally by the client and the IdP without the user noticing. When such a token expires, another (refresh) token can be used to create a new token, so that no new login is required. All this is done in the background and the user experience is basically the same as with a direct login or with SAML.
+OpenID Connect is based on exchanging data with JSON objects. It is an extension of the OAuth 2.0 protocol, which only handles authentication. The OpenID layer adds additional profile information and permissions, but uses OAuth for the basic authorization.
+Rather than working only with browser redirects like SAML, OpenID is based on OAuth and extensively uses direct communication ("backchannel") between the Relying Party and the IdP. Rather than documenting only a successful login, OpenID separates authentication (successfull login) and authorization (roles that grant user rights). It also does not rely on an active session at the IdP. Rather it generates a dedicated password (the "token") for the client and thus replaces the user's individual password with app-specific passwords, which are handled internally by the client and the IdP without the user noticing. When such a token expires, another (refresh) token can be used to create a new token, so that no new login is required. All this is done in the background and the user experience is basically the same as with a direct login or with SAML.
@@ Line 276: / Line 278: @@
 ===== C. Configuring Admidio with the Relying Party =====
-<WRAP center round todo 60%>
-todo box
-</WRAP>
+Once the client is set up to send authentication requests to Admidio, Admidio needs to be configured to respond to them. All OpenID clients (Relying Parties) are configured in the SSO Client Administration page, which can be reached from the SSO Preferences page (https://admidio.local/modules/preferences.php?panel=sso) from the SSO OIDC preferences page.
+{{ :en:2.0:sso:sso_saml_01-07_clientlist.png?direct&600 |}}
+To ensure only legitimate login requests from the real client are processed, Admidio needs the entity ID and the Redirect URI. In addition, Admidio will generate a Client Secret (a random string) that needs to be copied to the client's configuration and acts as a client password.
+The following settings are needed for setup. They MUST be consistent with the settings configured in the OpenID Connect client (RP).
+  * **Client ID** (unique identifier of the client): typically the URL of the OpenID client (RP)((Some RPs use basic auth by default, which does not allow special characters in the username. In this case, the URL MUST NOT be used, as this will prevent successful login! Other OpenID clients hardcode the client ID as their URL.))
+  * **Client Secret** (basically the client's password to access Admidio): Admidio will create this secret when the RP is created and will store it only as a hash in the database. Make sure to copy the secret before saving, as it is not possible to retrieve it later! One can, however, simply recreate a new secret and paste that into the RP's configuration.
+  * **Redirect URI** (where the user is redirected after successful login)
+  * **User ID field**: Whether the client gets the numeric Admidio user id, the globally unique UUID, or the user's login name as user ID
+  * **Permitted scopes**: OpenID defines certain groups of profile data, for which permission can be granted. The RP will include the scopes it is interested in in its login request, and the OpenID Provider (OP, Admidio in our case) will return the profile fields ("claims") corresponding to those scopes, if permission is given. The "openid" scope MUST always be present in OpenID!
+  * Further **profile data/fields** transmitted to the client on successful login
+  * Which **roles / group memberships** are sent to the client on successful login. The data fields and groups can be mapped to different names, if the client cannot handle Admidio's fields and role names. On particular case is the admin role, where many clients use a role named "admin" to grant admin access to a user logged in via OpenID.
+In addition each client typically has some more settings regarding fields <=> claims mapping, groups, auto-generating accounts for new logins, etc. The details depend on the capabilities of the client.
+{{:en:2.0:sso:sso_oidc_01-08_clientsetup1.png?direct&300|}}{{:en:2.0:sso:sso_oidc_01-09_clientsetup2.png?direct&300|}}{{:en:2.0:sso:sso_oidc_01-10_clientsetup3.png?direct&300|}}