Differences

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

--- en:2.0:single_sign_on [2025/05/05 01:25] – [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 293: / Line 295: @@
   * 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 settings to require sent or received SAML messages to be signed and/or encrypted to ensure a secure login process. The details depend on the capabilities of the client. Some clients do not support encryption, other require all SAML messages to be signed (for good reason!).
+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|}}