Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
en:2.0:single_sign_on [2025/05/04 20:10] – [B. Configuring an App (Relying Party) to use SSO with Admidio] kainhoferen:2.0:single_sign_on [2025/05/05 01:25] (current) – [C. Configuring Admidio with the Service Provider] kainhofer
Line 63: Line 63:
       - Admidio will show a "Client Secret", which must be copied to the client's config.        - Admidio will show a "Client Secret", which must be copied to the client's config. 
       - Select which scopes (classes of information) should be allowed to be sent to the client, and optionally select / map Admidio's profile fields and groups to OpenID claims (individual pieces/fields of information)       - Select which scopes (classes of information) should be allowed to be sent to the client, and optionally select / map Admidio's profile fields and groups to OpenID claims (individual pieces/fields of information)
-    - OpenID does NOT provide any automatic configuration of the client using metadata((There is an OpenID extension for dynamic/automatic client registration, but that has other complexities!)).+    - OpenID does NOT provide any automatic configuration of the client using metadata((There is an OpenID extension specification for dynamic/automatic client registration, but that has other complexities!)).
  
  
Line 188: Line 188:
 To ensure only legitimate login requests from the real client are processed, Admidio needs the entity ID, the URL for redirect as well as the x509 certificate (if messages are cryptographically signed). The following settings are needed for setup. They MUST be consistent with the settings configured in the SAML client (SP). Many SPs provide a Metadata XML link or file with all required settings included for automatic client setup. In Admidio's SAML client section, one can input the metadata URL and Admidio will pre-configure the client, but manual adjustments are possible (and in many areas even needed). To ensure only legitimate login requests from the real client are processed, Admidio needs the entity ID, the URL for redirect as well as the x509 certificate (if messages are cryptographically signed). The following settings are needed for setup. They MUST be consistent with the settings configured in the SAML client (SP). Many SPs provide a Metadata XML link or file with all required settings included for automatic client setup. In Admidio's SAML client section, one can input the metadata URL and Admidio will pre-configure the client, but manual adjustments are possible (and in many areas even needed).
  
-  * **Metadata URL** (for automatic setup of clients): https://[YOUR_ADMIDIO_URL]/modules/sso/index.php/saml/metadata +  * **Metadata URL** (for automatic setup of clients):  
-    * If your SP supports entering and loading the metadata XML, make sure to use it. It will load the correct settings from the SAML IdP and set up most settings correctly!{{ :en:2.0:sso:sso_saml_01-08a_clientsetup1_metadata.png?direct&400 |}} +    * If your SP provides a metadata URL, make sure to use it. It will load the correct settings from the SAML SP and set up most settings correctly!{{ :en:2.0:sso:sso_saml_01-08a_clientsetup1_metadata.png?direct&400 |}} 
-  * **IdP SAML Entity ID** (unique identifier of the Admidio instance): https://[YOUR_ADMIDIO_URL] +  * **Client ID** (unique identifier of the Client) 
-  * **SSO Endpoint** (where the SP sends the login request): https://[YOUR_ADMIDIO_URL]/modules/sso/index.php/saml/sso +  * **ACS URL** (where responses to login requests are sent to) 
-  * **SLO Endpoint** (where logout requests are sent to): https://[YOUR_ADMIDIO_URL]/modules/sso/index.php/saml/slo +  * **Single-Log-Out URL** (optional): Backchannel endpoint to log out from all clients 
-  * **x509 Certificate** (to allow clients to verify the cryptographic signatures): PEM-format needs to be copied out of the Admidio preferences+  * **x509 Certificate** (to allow verification of the messages sent by the SP): PEM-format needs to be copied out from the client
  
-  * **User ID**: Whether the client gets the numeric Admidio user id, the globally unique UUID, or the user's login name as user ID+  * **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
   * Further **profile data/fields** transmitted to the client on successful login   * 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 SAML.   * 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 SAML.
Line 276: Line 276:
 ===== C. Configuring Admidio with the Relying Party ===== ===== 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 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!).
 +
 +{{: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|}}
  
  • en/2.0/single_sign_on.1746382214.txt.gz
  • Last modified: 2025/05/04 20:10
  • by kainhofer