Show TOC

Procedure documentationProtecting Web Applications with SAML Locate this document in the navigation structure

 

Once you have configured a SAML 2.0 service provider to trust an identity provider, you can designate which resources are protected by SAML 2.0 and configure any custom requirements that go beyond that of the trust relationship.

Use this procedure to create a template so you can protect a large number of different resources with the same policy. This enables you to manage changes to a large number of resources by editing a single policy.

Prerequisites

  • You have configured the service provider for SAML.

  • You have configured a trusted identity provider for the service provider.

    For more information, see Trusting an Identity Provider.

Procedure

  1. Start the SAML 2.0 configuration application (transaction SAML2).

  2. Choose the Policies tab.

  3. In the Show field, enter Web Application Policies.

  4. Determine if you want to change an existing template or create a new one.

    • To create a new SAML 2.0 template, choose the Add pushbutton.

    • To change an existing template, select the template

  5. Choose the Edit pushbutton.

  6. Determine if you want to change the authentication policy.

    SAML 2.0 enables you to set an authentication policy for a protected resource with one of the following options:

    • To force an identity provider to always re-authenticate the user, even if the user already has an active session, choose 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.

    • Otherwise, enter None.

  7. In IdP-initiated single sign-on (SSO), determine if you want to change the authentication method in the HTTP request.

    • To set the HTTP request to use only a GET method, select Change to GET method. In such a case, the original method is replaced with GET regardless of the binding. This is the default setting.

      Note Note

      Some services may be configured not to accept direct POST requests without a special token for XSRF protection. For the services to obtain this token, the client must be authenticated. SAML 2.0 HTTP POST binding uses a POST request to the protected resource to perform authentication. However, since the client is not authenticated yet, it cannot obtain an XSRF protection token. The option Change to GET method helps avoiding this deadlock by changing the request method from POST to GET after successful IDP-initiated SSO. For more details about XSRF protection, see Cross-Site Request Forgery Protection under the Session Security Protection section in the Security Guide of SAP NetWeaver Gateway at http://help.sap.com/nwgateway.

      End of the note.
    • To preserve the original HTTP request method, select Preserve original method.

  8. Determine if you want to set any authentication contexts for this application on a particular identity provider.

    When you configured the trust of the identity provider, you could configure any authentication contexts that the identity provider must fulfill to authenticate a user wanting to access a resource on this service provider. For each SAML 2 template, you can override the default authentication contexts for a particular identity provider. Use this option if the authentication contexts are either too lax for the resources protected by the SAML 2 template.

    1. Under Trusted Identity Providers, select an identity provider.

    2. Under Authentication contexts for Identity Provider <provider name>, enter Custom in the Mode field.

    3. Add authentication contexts as required.

    4. Arrange the authentication contexts in the order you want them attempted.

  9. Save your entries.

  10. Use transaction SICF to select the SAML version and policy to protect the service with.

    For more information, see Logon Using SAML.

Result

Once you have configured how a resource is protected by SAML, ensure that the identity provider can fulfill the requirements you configured.