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

• Shibboleth config
• SAML config
• Upload keycloak configs
• Mappers
• Re-authentication

Shibboleth config

1. In the Admin Panel, make sure the active realm is Labforward.
2. Then add a new identity provider as SAML v2.0.

SAML config

1. 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.

2. This configuration file is going to prefill several configuration items. Scroll back to the SAML configuration section and check the changed attributes.

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.

3. 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.

1. Download the XML configuration from the Admin PAnel.
   1. On the SAML configuration, follow the link “Endpoints” for the SP descriptor.
   2. 
2. 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.)
3. Test the login from IAM.

Tip: In case the integration fails, you can check the logs of your IdP.

Mappers

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:

• givenName
• surname
• mail

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

Re-authentication

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.