An environment connected to SAMLtest (testing service) was set up, which runs a Shibboleth server as both IDP and SP (service provider) for testing. These are the steps for this configuration to be repeated on the subsequent installations with Shibboleth or other SAML-based Identity Providers.
TABLE OF CONTENTS
- In the Admin Panel, make sure the active realm is Labforward.
- Then add a new identity provider as SAML v2.0.
- For this configuration group, download the file from https://samltest.id/saml/idp and import it on the bottom of the section. For an actual IdP, the URL will be different.
- This configuration file is going to prefill several configuration items. Scroll back to the SAML configuration section and check the changed attributes.
|First Login Flow||iam-first-broker-login|
|Service Provider Entity ID||https://account.gha-iam-716-shibboleth-as-idp.dev.labforward.app/realms/labforward|
|Identity Provider Entity ID||https://samltest.id/saml/idp|
|SSO Service URL||https://samltest.id/idp/profile/SAML2/POST/SSO|
|Single Logout Service URL||We don’t want to log out the user in Shibboleth so, leave this field empty.|
Note: The Entity ID is the value that describes the IAM service as Service Provider. The other ones are related to Shibboleth configuration. The customer's administrators should provide these values.
- Save the configs.
Upload keycloak configs
For the SAMLTest server to work correctly, it’s necessary to upload the Service Provider configuration, so both applications trust each other.
- Download the XML configuration from the Admin PAnel.
- On the SAML configuration, follow the link “Endpoints” for the SP descriptor.
- Upload the XML file (don’t use the URL field) to SAMLTest: https://samltest.id/upload.php (Again, the URL will be different for an actual IdP.)
- Test the login from IAM.
Tip: In case the integration fails, you can check the logs of your IdP.
The fields from SAML IdP need to be mapped to Keycloak. Each Shibboleth instance might bring a different implementation for these attributes, but following the sample server, they are:
For each of these fields, it is necessary to create a new mapper with type “Attribute Importer”.
Sync Mode Override: import → This means we only ask the field for the first registration. This should be the option for all mappings from Shibboleth.
For the given attributes of this server, the mapping should be:
- givenName → firstName
- surname → lastName
- mail → email
Also, it is necessary to map a param with the type “Hardcoded User Session Attribute”:
Sync Mode Override: inherit → we should import this session attribute on every login
User Session Attribute: idp_user
User Session Value: true
Shibboleth IDP integration supports forcing re-authentication before critical actions. In general, it depends on the implementation of the Identity Provider to support this feature. If the Shibboleth instance respects the Force Authentication flag sent from IAM, it will always force user to authenticate before these critical actions.
The Force Authentication flag can be configured via the Admin Panel, in the Shibboleth/SAML IDP configuration. When it’s ON the user will be re-authenticated in Shibboleth every time. When it’s OFF, the IDP decides whether to reauthenticate or immediately redirect back to IAM with success since the user is already authenticated.
Final Note: For this article, we used the SAMLTest server as an example of SAML integration. The configuration should be similar to other IdPs supporting SAML protocol, such as Shibboleth. However, based on the internal configuration of the IdP, some extra steps might be needed to configure it during the setup.
Was this article helpful?
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
We appreciate your effort and will try to fix the article