Executing an Authorization-based Role Policy During SAML 2.0 Service Provider Initiated Request

Access Manager service provider federation profiles do not allow control-based authorization policies. Usually, the service providers enforce authorization rules. However, all service providers do not have this flexibility. It is recommended to not rely on a service provider to enforce such rules. You can apply an authorization policy to a configured service provider to allow or to not allow access to the service provider. Identity Server evaluates service providers and generates assertions.

Scenario: Company xyz.com uses a CRM application that is protected through a SAML 2.0 service provider. This application must be accessible only to the sales team. Whenever a user accesses the application through the service provider, it redirects to Identity Server for validating the user.

Figure 5-14 Executing Authorization Policy Based on Role

Identity Server authenticates a user and then verifies whether the user is a member of the sales team. If yes, Identity Server sends a successful assertion to the service provider. Else, Identity Server sends an error response to the service provider.

By default, Identity Server runs these authorization policies after a user is authenticated during spsend. Set ALLOW_AUTH_POLICY_EXECUTION to false to disable Identity Server executing the authorization policies. To set this option, see Configuring Identity Server Global Options.

If the authorization policy is configured to deny execution, Identity Server sends the following message as part of an assertion response:

<samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"> <samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" /> </samlp:StatusCode> <StatusMessage>Authorization is failed</StatusMessage> </samlp:Status>

For information about configuring a brokering for authorization of service providers, see Configuring a Brokering for Authorization of Service Providers.