Show TOC

Protecting Web Applications with SAMLLocate this document in the navigation structure


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


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.


  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 reauthenticate 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 this case, the original method is replaced with GET regardless of the binding. This is the default setting.
      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 to avoid 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.
    • 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.

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

    1. Under the Policies tab, select the trusted identity provider.

    2. Choose the Edit button.

    3. Under Authentication Contexts Settings for Identity Provider <provider name> , select No for the User Default Settings field.

    4. Add authentication contexts as required.

    5. Arrange the authentication contexts in the order you want them to be 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.


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