By default, all Internet Communication Framework (ICF) services that are to be accessed using HTTP have the SAML authentication mechanism enabled. You can use this procedure to configure SAML authentication at service level.
Security session management is active
For more information, see Activating HTTP Security Session Management on AS ABAP
The SAML 2.0 local provider is created in the client
For more information, see Configuring AS ABAP as a Service Provider.
There is trust to at least one identity provider
For SAML communication to be functional, there needs to be established trust between the local service provider and an identity provider. For more information, see Trusting an Identity Provider.
Using SAML 2.0 in the ICF Logon Procedure
You specify the ICF logon procedure by using the Procedure option in the Logon Data tab of the selected service. You can use SAML 2.0 authentication in one of the two options:
Standard logon procedure
By default, each ICF service is configured with a standard logon procedure consisting of eight authentication mechanisms. SAML authentication is at seventh place, sorted from top priority down. If an HTTP request delivers credentials for one of the six mechanisms before SAML, they will be processed by the corresponding mechanism, and SAML will not be triggered.
Alternative logon procedure
If you choose the Alternative Logon Procedure option, you can remove some of these mechanisms from the list but you cannot change their priorities.
Unlike the rest of the authentication mechanisms in the list, SAML 2.0 does not rely on credentials contained in the HTTP request. ICF will trigger SAML 2.0 authentication if the HTTP request does not contain credentials for any of the six mechanisms, and the prerequisites for SAML authentication are met.
If you use the standard logon procedure, and your Web browser is configured always to send a client certificate for authentication, there will be no SAML 2.0 authentication, since client certificate logon will be triggered.
If you want to have basic authentication as a fallback variant for SAML 2.0 authentication, use the Alternative logon procedure, leaving only the Basic authentication and SAML 2.0 authentication in the list. In this case, SAML will be triggered before basic authentication, although basic authentication is higher in the list. If SAML authentication fails, basic authentication will be triggered.
Changing the SAML Configuration of an ICF Service
Double click the service node.
In the Logon Data tab, choose Change.
The data becomes editable.
Choose the SAML Configuration pushbutton.
Deselect the Use Configuration Data from Superordinate Node option.
By default, this option is selected. It means the node will inherit the configuration of the superordinate node.
If necessary, specify the SAML 2.0 logon policy as required.
Specifying SAML 2.0 Logon Policies
Policies apply specific authentication logic when a protected resource is requested.
To force an identity provider to always re-authenticate the user, even if the user already has an active session, choose a policy configured to require forced re-authentication. Use this option to protect particularly sensitive applications, by ensuring the user is who he or she claims to be.
To require the identity provider to only use authentication methods that do not require user interaction, such as certificate logon, enter passive authentication. Use this option if the process of logging on would disorient or worry the user.
You create SAML 2.0 logon policies in the SAML configuration user interface. For more information, see Protecting Web Applications with SAML.
There are two ways to specify a logon policy:
At an ICF service level
You can set a logon policy at ICF service level only from the default client (000).
In this case, make sure the policy is available on all clients. Otherwise, SAML authentication will fail on the clients where the policy is missing.
At an external alias level
You can set a logon policy at external alias level from any client.
In this case, the logon policy you set will override all policy configurations for that service on all clients. For example, the administrator of client 001 sets policy A to service B. Later, the administrator of client 002 sets policy C to service B. As a result, service B will have policy C, since the latest changes override all existing policy configurations on all clients.
We recommend that you use virtual hosts for different clients. Virtual hosts can be configured separately for each client.
Disabling SAML 2.0 Authentication
There are three alternative ways to disable SAML 2.0 authentication:
By disabling the SAML local provider
For more information, see Disabling the SAML Service Provider.
By disabling the SAML trusted providers
If there is no active trusted provider configured, SAML authentication cannot function.
By calling the protected resource with URL parameter "saml2" set to "disabled"