SAML Single Sign-on

ivanti connect secure saml 2 0 sso solutions this section provides a brief overview of the security assertion markup language (saml) standard produced and approved by the organization for the advancement of structured information standards (oasis) understanding saml 2 0 this topic provides a reference to the security assertion markup language (saml) standard and an overview of saml 2 0 use cases about saml saml is an xml based framework for communicating user authentication, entitlement, and attribute information the standard defines the xml based assertions, protocols, bindings, and profiles used in communication between saml entities saml is used primarily to implement web browser single sign on (sso) saml enables businesses to leverage an identity based security system like ivanti connect secure to enforce secure access to web sites and other resources without prompting the user with more than one authentication challenge for complete details on the saml standard, see the oasis web site http //www oasis open org/committees/tc home php?wg abbrev=security saml use cases this section provides a brief summary of the primary saml use cases saml sso saml is primarily used to enable web browser single sign on (sso) ivanti secure access client (win and mac) also supports saml sso the user experience objective for sso is to allow a user to authenticate once and gain access to separately secured systems without resubmitting credentials the security objective is to ensure the authentication requirements are met at each security checkpoint in an sso transaction, the saml services implemented at each secured system exchange requests and assertions to determine whether to allow access the saml assertions used in sso transactions include authentication statements and attribute statements saml acl saml can also be used to enforce access control list (acl) permissions in an acl transaction, the saml services implemented for each secured system exchange assertions to determine whether a user can access the resource the saml assertions used in acl transactions include authorization requests and authorization decision statements saml 2 0 supported features reference this topic provides an overview of ivanti connect secure support for security assertion markup language (saml) single sign on (sso) it includes the following information related to saml 2 0 support supported saml sso deployment modes docid\ w8him5gdqsv75bqt xjlr supported saml sso profiles docid\ w8him5gdqsv75bqt xjlr fips support notes docid\ w8him5gdqsv75bqt xjlr supported saml sso deployment modes in a saml deployment, a saml service provider is a secured resource (an application, web site, or service) that is configured to request authentication from a saml identity provider the saml identity provider responds with assertions regarding the identity, attributes, and entitlements (according to your configuration) the exchange enforces security and enables the sso user experience the system can act as a saml service provider, a saml identity provider, or both the following sections provide illustrations ivanti connect secure as a saml service provider docid\ w8him5gdqsv75bqt xjlr ivanti connect secure as a saml identity provider (gateway mode) docid\ w8him5gdqsv75bqt xjlr ivanti connect secure as a saml identity provider (peer mode) docid\ w8him5gdqsv75bqt xjlr ivanti connect secure as a saml service provider if you are working with a partner that has implemented a saml identity provider, you can deploy the system as a saml service provider to interoperate with it, thereby enabling sso for users who should have access to resources in both networks in this model, the user is authenticated by the saml identity provider the system uses the saml response containing the assertion to make an authentication decision the choices the identity provider makes to implement saml determine the deployment choices, for example whether to use saml 2 0, whether to reference a published metadata configuration file, and whether to use a post profile when you deploy the system as a saml service provider, you create a saml authentication server configuration that references the partner saml identity provider, and a set of access management framework objects (realm, role mapping rules, and sign in policy) that reference the saml authentication server when you configure the saml service provider, some particular settings are necessary to support either identity provider initiated or service provider initiated sso the documentation for the configuration steps makes note of these settings regardless, you configure the saml service provider to support both identity provider initiated and service provider initiated sso the following figure illustrates the flow of network communication in a service provider initiated sso scenario with a web browser client the following figure depicts the ivanti connect secure as a saml service provider in a service provider initiated sso scenario 1 the user clicks a link to access a resource 2a the service provider sends an http redirect status code (http 302) to the user the saml request and all other saml details are sent as url parameters in the url location header 2b the user sends an http get request to the identity provider the saml request and all other saml details are sent as url parameters if the user already has a session with the identity provider, steps 2 1 and 2 2 are skipped 2 1 if the user does not have a session, the identity provider sends an authentication challenge to the user 2 2 the user enters sign in credentials 3a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 3b the user sends the form to the service provider 4 the external resource is delivered to the user's browser the following figure illustrates the flow of network communication in an identity provider initiated sso scenario with a web browser client the following figure depicts the ivanti connect secure as a saml service provider in an identity provider initiated sso scenario 1 the user authenticates to the identity provider 2 the identity provider returns a portal page with links to external resources 3 the user clicks a link for an external resource 4a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 4b the user sends the form to the service provider 5 the external resource is delivered to the user's browser the following figure illustrates the flow of network communication when a user clicks a ivanti secure access client connection the figure depicts the ivanti connect secure as a saml service provider in a ivanti secure access client initiated connection 1 the user clicks the ivanti secure access client connection the ivanti client and system exchange if t/tls messages the ivanti client learns that authentication is a saml exchange, and ivanti launches its embedded client web browser 2a the service provider sends an http redirect status code (http 302) to the user the saml request and all other saml details are sent as url parameters in the url location header 2b the user sends an http get request to the identity provider the saml request and all other saml details are sent as url parameters if the user already has a session with the identity provider, steps 2 1 and 2 2 are skipped 2 1 if the user does not have a session, the identity provider sends an authentication challenge to the user 2 2 the user enters sign in credentials 3a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 3b the user sends the form to the service provider 4 the setup client is run on the endpoint, and the ivanti secure access client and system set up an ssl vpn tunnel ivanti connect secure as a saml identity provider (gateway mode) when you deploy the system in front of enterprise resources that support saml and have been configured as a saml service provider, the system acts as a gateway for user access to the secured resource, just as it does with its other resource policies in the saml exchange, the system acts as a saml identity provider when deployed as a gateway, the saml sso communication is always identity provider initiated the system maintains the session and uses its rewriting or pass through proxy features to render data to the user in a gateway mode deployment, you configure the system as a saml identity provider to correspond with the saml service provider, and you create a saml sso resource policy configuration to determine the users and resources to which the saml sso experience applies the saml sso resource policy supports two types of behavior that are possible with the http responses sent by saml service providers the saml service provider sends http responses that can be handled by http cookies and therefore do not require user interaction in this case, the saml sso resource policy can be configured to use cookies to handle the http transaction the saml service provider sends http responses that require user interaction for example, the saml service provider might send an http 200 ok with an embedded form that requires action from the user, execution of javascript, or data to be automatically submitted on load or, the resource might send an http 3xx redirect that requires acceptance by the user in these cases, the saml sso resource policy can be configured to forward the http responses through the rewriter, which rewrites the http response and sends it to the end user the following figure illustrates the communication that occurs when the saml sso policy is configured to handle the saml service provider responses using cookies ivanti connect secure as a saml identity provider (gateway mode) user/browser action not required 1 user requests a saml protected resource 2 the system executes the saml sso policy and the identity provider sends an http request containing the saml assertion to the saml service provider 3 the saml service provider sends an http response the saml sso process extracts the cookies from the response and stores them in the cookie cache 4 the system rewriter process sends the request for the resource (sending the cookies received in step 3) 5 the saml service provider sends the resource 6 the system rewrites the resource and sends it to the user the following figure illustrates the communication that occurs when the saml sso policy is configured to rewrite the saml service provider responses and send them to the user/browser for action the following figure depicts the ivanti connect secure as a saml identity provider (gateway mode) user/browser action required 1 user requests a saml protected resource 2 the system executes the saml sso policy and the system identity provider sends an http request containing the saml assertion to the saml service provider 3 the saml service provider sends an http response the system saml sso process forwards the entire response to the rewriter 3 1 the rewriter rewrites the response and sends it to the user 3 2 the user/browser completes any action required and sends a response (an http get/post request) 4 the rewriter processes it as any other http web request and forwards to the saml service provider 5 the saml service provider sends the resource 6 the system rewrites the resource and sends it to the user steps 5 and 6 can involve many transactions related to web browsing or use of the resource ivanti connect secure as a saml identity provider (peer mode) when deployed to support access to external resources (for example, public cloud resources), the system does not have to be a gateway to user access the user can access the external resource directly, and the traffic does not flow through the device in a peer mode deployment, you configure the system as a saml identity provider to correspond with the external saml service provider, and you create a saml external apps sso resource policy configuration to determine the users and resources to which the saml sso experience applies in a service provider initiated sso scenario, the user requests a resource protected by the saml service provider the saml service provider redirects the user to the sign in page the access management framework processes the authentication request, performs host checking rules and role mapping rules if authentication is successful, the system redirects the user to the protected resource in an identity provider initiated sso scenario, the user first creates a session the access management framework processes are run when the user signs in the saml external apps sso policy is enforced when the user browses to the saml protected external application when you configure the saml identity provider, some settings are necessary to support either identity provider initiated or service provider initiated sso the documentation for the configuration steps makes note of these settings regardless, you configure the saml identity provider to support both identity provider initiated and service provider initiated sso the following figure illustrates the flow of network communication in a service provider initiated sso scenario ivanti connect secure as a saml identity provider (peer mode) in a service provider initiated sso scenario 1 the user clicks a link to access a resource 2a the service provider sends an http redirect status code (http 302) to the user the saml request and all other saml details are sent as url parameters in the url location header 2b the user sends an http get request to the identity provider the saml request and all other saml details are sent as url parameters if the user already has a session with the identity provider, steps 2 1 and 2 2 are skipped 2 1 if the user does not have a session, the identity provider sends an authentication challenge to the user 2 2 the user enters sign in credentials 3a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 3b the user sends the form to the service provider 4 the external resource is delivered to the user's browser the following figure illustrates the flow of network communication in an identity provider initiated sso scenario ivanti connect secure as a saml identity provider (peer mode) in an identity provider initiated sso scenario 1 the user authenticates to the identity provider 2 the identity provider returns a portal page with links to external resources 3 the user clicks a link for an external resource 4a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 4b the user sends the form to the service provider 5 the external resource is delivered to the user's browser supported saml sso profiles the following table summarizes support for saml 2 0 deployment profiles profile message flows binding service provider identity provider (gateway) identity provider (peer) web browser sso \<authnrequest> from service provider to identity provider http redirect supported supported http post not supported supported identity provider \<response> to service provider http post supported supported supported authentication context classes sent in \<requestedauthncontext> http post all authentication context classes password protected, timesynctoken, and tlsclient only basic attribute profile simple \<attribute> statements (name value pairs) as part of assertions http post consumes and stores attribute statements sends attribute statements sends attribute statements single logout logout request http redirect supported not supported not supported http post not supported not supported not supported soap not supported not supported not supported logout response http redirect supported not supported not supported http post not supported not supported not supported soap not supported not supported not supported ivanti connect secure does not act as an attribute authority fips support notes historically, in fips deployments, private keys were managed in a way that can be problematic for saml functionality that depends on access to the private key the following table summarizes our support for saml for fips deployments the following table describes the saml support for fips deployments saml 2 0 release service provider identity provider 8 0 and above device certificate signing is supported; however, the ecdsa certificates is not supported there are no other limitations device certificate signing is supported; however, the ecdsa certificates is not supported there are no other limitations saml 2 0 configuration tasks this section includes the tasks you perform to enable and configure saml services configuring system wide saml settings this section describes tasks related to configuring system wide saml settings configuring global saml settings the system wide saml settings impact all saml service provider and identity provider instances to configure global saml settings select system > configuration > saml click the settings button to display the configuration page complete the settings described in the following table click save changes the following table lists saml global configuration guidelines settings guidelines timeout value for metadata fetch request specify the number of seconds after which a download request is abandoned if the peer saml entity publishes its metadata at a remote location, the system downloads the metadata file from the specified location validity of uploaded/downloaded metadata file specify the maximum duration for which the system considers the metadata file of the peer saml entity to be valid if the metadata file provided by the peer saml entity contains validity information, the lower value takes precedence host fqdn for saml specify the fully qualified domain name for the ivanti connect secure host the value you specify here is used in the saml entity id and the urls for saml services, including entity id for saml service provider and saml identity provider instances the saml entitiy id is the url where the system publishes its saml metadata file single sign on service url single logout service url assertion consumer service url best practice the system uses https for these services therefore, we recommend that you assign a valid certificate to the interface that has the ip address to which this fqdn resolves so that users do not see invalid certificate warnings alternate host fqdn for saml optional if you have enabled the reuse existing nc (ivanti) session on the saml identity provider sign in page, specify the fully qualified domain name used to generate the sso service url set up your dns service to ensure that the alternate hostname resolves to a different ip address when a session is established and when not established we recommend the following dns behavior if the nc (ivanti ) session is not established, the ip address of the alternate hostname should resolve to the public ip address on the device external port if the nc (ivanti ) session is established, the ip address of the alternate hostname should resolve to the private ip address on the device internal port best practice the system uses https for this service therefore, we recommend that you assign a valid certificate to the interface that has the ip address to which this fqdn resolves so that users do not see invalid certificate warnings update entity ids use this button to regenerate the saml entity ids of all configured service providers and identity providers typically, you take this action when the host fqdn for saml is changed managing saml metadata files you use the system > configuration > saml pages to maintain a table of saml metadata files for the saml service providers and identity providers in your network using saml metadata files makes configuration easier and less prone to error you can add the metadata files to the system by uploading a metadata file retrieving the metadata file from a well known url to add metadata files select system > configuration > saml click new metadata provider to display the configuration page complete the settings described in the following table save the configuration the following table lists the saml metadata provider configuration guidelines settings guidelines metadata provider location configuration select one of the following methods local browse and locate the metadata file on your local host or file system remote enter the url of the metadata file only http and https protocols are supported metadata provider verification configuration accept untrusted server certificate if you specify a url for the metadata provider, select this option to allow the system to download the metadata file even if the server certificate is not trusted this is necessary only for https urls accept unsigned metadata if this option is not selected, unsigned metadata is not imported signed metadata is imported only after signature verification signing certificate browse and locate the certificate that verifies the signature in the metadata file this certificate overrides the certificate specified in the signature of the received metadata if no certificate is uploaded here, then the certificate present in the signature of the received metadata is used select the enable certificate status checking option to verify the certificate before using it certificate verification applies both to the certificate specified here and the certificate specified in the signature in the metadata file metadata provider filter configuration roles select whether the metadata file includes configuration details for a saml service provider or identity provider you may select more than one if you select a role that is not in the metadata file, it is ignored if none of the selected roles are present in the metadata file, the system returns an error entity ids to import enter the saml entity ids to import from the metadata files enter only one id per line leave this field blank to import all ids this option is available only for uploading local metadata files the refresh button downloads the metadata files from the remote location even if these files have not been modified this operation applies only to remote locations; local metadata providers are ignored if selected to refresh a metadata file select system > configuration > saml select the metadata file to refresh and click refresh to delete a metadata file select system > configuration > saml select the metadata file to delete and click delete configuring ivanti connect secure as a saml 2 0 service provider this topic describes how to configure the system as a saml service provider when the system is a saml service provider, it relies on the saml identity provider authentication and attribute assertions when users attempt to sign in to the device note that authentication is only part of the security system the access management framework determines access to the system and protected resources the system supports http redirect binding for sending authnrequests http redirect binding for sending/receiving singlelogout requests/responses http post bindings for receiving saml responses requestedauthncontext context class specifications before you begin check to see whether the saml identity provider uses http post bindings for saml assertions check to see whether the saml identity provider has published a saml metadata file that defines its configuration if the saml identity provider metadata file is available, configuration is simpler and less prone to error complete the system wide saml settings if you have not already done so select system > configuration > saml > settings for details, see configuring global saml settings docid\ w8him5gdqsv75bqt xjlr add metadata for the saml identity provider to the metadata provider list if you have not already done so select system > configuration > saml for details, see managing saml metadata files docid\ w8him5gdqsv75bqt xjlr the sign in url for which a session needs to be established for the system as a service provider is identified by the relaystate parameter ( html form parameter for post ) in a service provider initiated case, the system populates relaystate as an http url parameter while sending authnrequest in the idp initiated scenario (ivanti connect secure is a service provider and there is a third party idp), the idp must be configured to set the appropriate sign in url of the system in the relaystate parameter of the html form containing the saml response for more information, see the saml 2 0 specification to configure the system as a saml service provider select authentication > auth servers select saml server from the new list and then click new server to display the configuration page complete the settings as described in the table docid\ w8him5gdqsv75bqt xjlr save the configuration after you save changes for the first time, the page is redisplayed and now has two tabs use the settings tab to modify any of the settings pertaining to the saml server configuration use the users tab to monitor user sessions next steps configure the access management framework to use the saml authentication server start with realm and role mapping rules for details, see " creating an authentication realm docid\ njc3m md5dcwo94zhduxq " and specifying role mapping rules for an authentication realm docid\ njc3m md5dcwo94zhduxq configure a sign in policy when using a saml authentication server, the sign in policy can map to a single realm only for details, see defining a sign in policy docid\ skxsfmzapseauxsqr4hrx the following table lists the saml service provider profile settings guidelines name specify a name to identify the server instance settings saml version select 2 0 sa entity id this value is prepopulated it is generated by the system, based on the value for the host fqdn for saml setting on the system > configuration > saml > settings page configuration mode select manual or metadata if a metadata file or location is available from the saml identity provider, use the metadata option to make configuration simpler and less prone to error to upload or set the location for the published metadata file, select system > configuration > saml and click the new metadata provider button identity provider entity id the identity provider entity id is sent as the issuer value in the assertion generated by the saml identity provider if you use the metadata option, this setting can be completed by selecting the identity provider entity id from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page if you complete this setting manually, specify the issuer value in assertions generated by the saml identity provider typically, you ask the saml identity provider administrator for this setting identity provider single sign on service url the identity provider sso service url is a url provisioned by the saml identity provider the setting is required to support service provider initiated sso if missing, the system cannot successfully redirect the user request if you use the metadata option, this setting can be completed by selecting the sso service url from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page if you complete this setting manually, ask the saml identity provider administrator for this setting user name template specify how the system is to derive the username from the assertion if the field is left blank, it uses the string received in the nameid field of the incoming assertion as the username if you choose a certificate attribute with more than one value, the system uses the first matched value for example, if you enter \<certdn ou> and the user has two values for the attribute (ou=management, ou=sales), the system uses "management" to use all values, add the sep attribute to the variable for example, if you enter \<certdn out sep=" ">, the system uses "management\ sales" the attributes received in the attribute statement in the incoming assertion are saved under userattr these variables can also be used with angle brackets and plain text if the username cannot be generated using the specified template, the login fails if the nameid filed of the incoming assertion is of type x509nameformat, then the individual fields can be extracted using system variable "assertionnamedn" allowed clock skew (minutes) specify the maximum allowed difference in time between the system clock and the saml identity provider server clock note saml is a time sensitive protocol the time based validity of a saml assertion is determined by the saml identity provider if the saml identity provider and saml service provider clocks are askew, the assertion can be determined invalid, and you will receive the following error "saml transferred failed please contact your system administrator detail failure no valid assertion found in saml response " we recommend you use ntp to ensure the clocks are synchronized and that you set an allowed clock skew value that accommodates any expected or permissible skew support single logout single logout is a mechanism provided by saml for logging out a particular user from all the sessions created by the identity provider select this option if the system must receive and send a single logout request for the peer saml identity provider if you use the metadata option, the single logout service url setting can be completed by selecting the slo service url from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page the system sends single logout requests to this url in addition, if you use the metadata option, the single logout response url setting is completed based on your selection for single logout service url if the identity provider has left this setting empty in its metadata file, the system sends the single logout response to the slo service url if you complete these settings manually, ask the saml identity provider administrator for guidance the support single logout service for the identity provider must present a valid certificate for example, the hostname in a single logout request url must be the same as the common name of the certificate presented by the identity provider of that hostname if an invalid certificate is presented, the single logout feature may not work as intended sso method post when configured to use the post binding, the system uses a response signing certificate to verify the signature in the incoming response or assertion the certificate file must be in pem or der format the certificate you select should be the same certificate used by the identity provider to sign saml responses complete the following settings to configure saml using the http post binding response signing certificate if you use the metadata based configuration option, select a certificate from the list the list is populated by the identity provider entities defined in metadata files added to the system > configuration > saml page if you configure these settings manually, browse to and upload the certificate to be used to validate the signature in the incoming response or assertion if no certificate is specified, the certificate embedded in the response is used enable signing certificate status checking select this option to check the validity of the signing certificate before verifying the signature this setting applies to any certificate used for signature verification if this option is enabled, the response will be rejected if the certificate is revoked, expired, or untrusted if this option is selected, the certificate ca must be added to the system trusted client ca store if this option is not enabled, then the certificate is used without any checks select device certificate for signing select the device certificate the system uses to sign the authnrequest sent to the identity provider sso service if you do not select a certificate, the system does not sign authnrequest select device certificate for encryption select the device certificate the system uses to decrypt encrypted data received in the saml response the public key associated with the device certificate is used by the identity provider for encryption authentication context classes use the add and remove buttons to select authentication context classes to be sent in the authentication requests to the saml identity provider these are included in the requestedauthncontext element in the oasis standard, an authentication context is defined as "the information, additional to the authentication assertion itself, that the relying party may require before it makes an entitlements decision with respect to an authentication assertion " this feature supports all authentication context classes specified in the saml 2 0 oasis authn context specification for example, if you select x509, the system sends the following context \<samlp\ requestedauthncontext> \<saml\ authncontextclassref xmlns\ saml="urn\ oasis\ names🇹🇨saml 2 0\ assertion"> urn\ oasis\ names🇹🇨saml 2 0🇦🇨classes\ x509\</saml\ authncontextclassref> \</samlp\ requestedauthncontext> in response, the saml idp sends the context data along with the authentication results the system stores the context data in the session cache, and it can be specified in user attribute role mapping rules specify a comparison attribute within the requestedauthncontext element the comparison attribute specifies the relative strengths of the authentication context classes specified in the request and the authentication methods offered by a saml idp the following values specified in the saml 2 0 oasis core specification can be selected exact requires the resulting authentication context in the authentication statement to be the exact match of at least one of the authentication contexts specified minimum requires the resulting authentication context in the authentication statement to be at least as strong as one of the authentication contexts specified maximum requires the resulting authentication context in the authentication statement to be stronger than any one of the authentication contexts specified better requires the resulting authentication context in the authentication statement to be as strong as possible without exceeding the strength of at least one of the authentication contexts specified select the same value that is configured on the saml idp if none is specified in the saml idp configuration, the implicit default is exact service provider metadata settings metadata validity enter the number of days the system metadata is valid valid values are 0 to 9999 0 specifies the metadata does not expire do not publish sa metadata select this option if you do not want the system to publish the metadata at the location specified by the system service entity id field download metadata this button appears only after you have saved the authentication server configuration use this button to download the metadata of the current saml service provider user record synchronization enable user record synchronization allow users to retain their bookmarks and individual preferences regardless of which device they log in to logical auth server name specify the server name if you have enabled user record synchronization configuring ivanti connect secure as a saml 2 0 identity provider this topic describes how to configure the system as a saml identity provider configuration overview implementing the system as a saml identity provider includes the following basic steps configure system wide saml settings select system > configuration > saml > settings see configuring global saml settings docid\ w8him5gdqsv75bqt xjlr add saml metadata provider files select system > configuration > saml see managing saml metadata files docid\ w8him5gdqsv75bqt xjlr configure sign in saml metadata provider settings see configuring sign in saml metadata provider settings docid\ w8him5gdqsv75bqt xjlr configure sign in saml identity provider settings see configuring sign in saml identity provider settings docid\ w8him5gdqsv75bqt xjlr configure peer service provider settings see configuring peer saml service provider settings docid\ w8him5gdqsv75bqt xjlr configure a resource policy for gateway mode deployments, configure a saml sso resource policy see configuring a saml sso resource policy for gateway mode deployments docid\ w8him5gdqsv75bqt xjlr for peer mode deployments, configure a saml sso external applications policy see configuring a saml external applications sso policy docid\ w8him5gdqsv75bqt xjlr configuring sign in saml metadata provider settings sign in saml metadata provider settings determine how the system identity provider metadata is published to configure the identity provider metadata publication settings select authentication > signing in > sign in saml > metadata provider to display the configuration page complete the settings described in the following table click save metadata provider to save your changes the following table lists the sign in saml identity provider metadata provider configuration guidelines settings guidelines entity id this value is prepopulated it is generated by the system, based on the value for the host fqdn for saml setting on the system > configuration > saml > settings page metadata validity specify the maximum duration for which a peer saml entity can cache the system saml metadata file valid values are 1 to 9999 the default is 365 days do not publish sa metadata select this option if you do not want the system to publish the metadata at the location specified by the system entity id field you can use this option to toggle off publication without deleting your settings download metadata use this button to download the system saml identity provider metadata configuring sign in saml identity provider settings the settings defined in this procedure are the default settings for the system saml identity provider communication with all saml service providers if necessary, you can use the peer service provider configuration to override these settings for particular service providers to configure sign in saml identity provider settings select authentication > signing in > sign in saml > identity provider to display the configuration page complete the settings described in the following table save the configuration the following table lists the sign in saml identity provider configuration guidelines settings guidelines basic identity provider (idp) configuration (published in metadata) protocol binding to use for saml response only post is supported signing certificate select the certificate used to sign the saml messages sent by the system the certificates listed here are configured on the system > configuration > certificate > device certificates page decryption certificate select the certificate used to decrypt the saml messages sent by peer service providers the public key associated with this certificate is used by the peer service provider to encrypt saml messages exchanged with this identity provider the decryption certificate must be configured if the peer service provider encrypts the saml messages sent to the system the certificates listed here are configured on the system > configuration > certificate > device certificates page other configurations reuse existing nc (pulse) session this feature applies to a service provider initiated sso scenario that is, when a user clicks a link to log into the service provider site the service provider redirects the user to the identity provider sso service url if this option is selected, a user with an active nc/ivanti session is not prompted to authenticate the system uses information from the existing session to form the saml response accept unsigned authnrequest in a service provider initiated sso scenario, the sp sends an authnrequest to the identity provider this authnrequest could be either signed or unsigned if this option is unchecked, the system rejects unsigned authnrequests note that the system also rejects signed authnrequests if signature verification fails sign saml assertion saml assertion will also be signed along with signing the saml response by default individual sps can choose to accept only signed saml assertion service provider related idp configuration relay state saml relaystate attribute sent to the service provider in an identity provider initiated sso scenario if left blank, the relaystate value is the url identifier of the resource being accessed session lifetime suggest a maximum duration of the session at the service provider created as a result of the saml sso select one of the following options none the identity provider does not suggest a session duration role based suggest the value of the session lifetime configured for the user role customized if you select this option, the user interface displays a text box in which you specify a maximum in minutes sign in policy select the sign in url to which the user is redirected in a service provider initiated scenario the list is populated by the sign in pages configured on the authentication > signing in > sign in policies page the user is not redirected if he or she already has a session with the system and had authenticated through this sign in policy force authentication behavior in an service provider initiated scenario, the service provider sends an authnrequest to the identity provider if the service provider authnrequest includes the forceauthn attribute set to true and the user has a valid session, this setting determines how the identity provider responds select one of the following options reject authnrequest do not honor the saml sso request re authenticate user invalidate the user session and prompt for re authentication this setting prevails over the ivanti session reuse setting user identity subject name format format of the nameidentifier field in the generated assertion select one of the following options dn username in the format of dn (distinguished name) email address username in the format of an e mail address windows username in the format of a windows domain qualified username other username in an unspecified format subject name template for generating the username that is sent as the value of the nameidentifier field in the assertion you may use any combination of available system or custom variables contained in angle brackets and plain text attribute statement configuration attributes to be sent in saml attribute statements can be specified manually as name value pairs, or you can configure an option to fetch name value pairs from an ldap server (or you can specify both manual entries and ldap entries) attribute name an ascii string friendly name a more readable friendly name for the attribute this is optional (an option included in the saml standard) attribute value the attribute value can be specified as a hard coded string, a custom variable, or a user attribute variable system conventions for specifying user and custom tokens and variables apply the value can be a combination of a string and a user or custom variable for example email \<customvar email> the value can also be a combination of user and custom variables and hardcoded text for example mydata=\<user>\<realm>\<customvar email> value type select single valued or multivalued a single valued attribute can be a combination of a string and a user or custom variable if there are multiple single valued attributes configured with the same attribute names, they are combined and sent as a multivalued attribute select multivalue if you want every individual token defined in the attribute value column to be sent as a separate attributevalue for example \<element ref="saml\ attributevalue" minoccurs="0" maxoccurs="unbounded"/> if the attribute value is given as \<user>mars\<realm>ivanti\<role> and the value type is marked as multivalued, then the values sent as part of attribute statement are sent as follows username realmname role note that only the tokens \['<>'] will be considered when processing a multivalued attribute marked the remaining data (for example mars, jupiter) is discarded specifying the token \<role> will send only one role to send all roles, specify the attribute value with the syntax \<role sep=","> if you specify \<role sep=","> as a single valued attribute, it is sent as a single string with "," separated roles if you specify \<role sep=","> as a multi valued attribute, each role is sent in a separate \<attributevalue> element encryption is set at the assertion level you cannot encrypt individual attributes directory server to fetch attribute name value pairs from an ldap server, complete the following settings directory server select the ldap server from the list you must add the ldap server to the authentication > auth servers list before it can be selected username for lookup enter a username template for ldap lookup the default is the variable \<username> the \<username> variable stands for the login credential the user entered when logging in the value can contain contextual characters as well as variables for substitution attribute name type an ldap attribute name, such as cn the attribute name is fetched from the ldap server and sent as saml attribute statements as part of a saml assertion friendly name a more readable friendly name for the attribute this is optional (an option included in the saml standard) with the ldap option, the saml idp sends attributes in the form configured on the backend ldap server if the ldap server returns an attribute value in multi valued form, then the saml attribute statement will also be in multi valued form configuring peer saml service provider settings the peer service provider list defines the set of service providers configured to communicate with the system saml identity provider when you add a peer service provider to the list, you can customize the saml identity provider settings used to communicate with the individual service provider if the service provider provides a saml metadata file, you can use it to simplify configuration, or you can complete more detailed manual steps if available, we recommend you use metadata so that configuration is simpler and less prone to error to configure peer saml service provider settings select authentication > signing in > sign in saml > identity provider under peer service provider configuration, create a list of service providers that are saml peers to the system saml identity provider to add a service provider to the list, click add sp to display the configuration page complete the settings described in the following table save the configuration the following table lists the peer service provider configuration guidelines settings guidelines configuration mode select manual or metadata service provider configuration metadata entity id if you use metadata, select the saml entity id of the service provider this list contains all the service providers specified in all the metadata files added to the system > configuration > saml page select certificates manually when you use the metadata configuration, the system saml identity provider iterates through all the signature verification certificates specified when verifying the incoming saml messages coming from the service provider similarly, when encrypting the saml messages going out, the system saml identity provider encrypts the messages with the first valid encryption certificate encountered in the metadata select this option to override this default behavior and select certificates manually signature verification certificate if you select the select certificates manually option, select the certificate to be used by the identity provider to verify the signature of incoming saml messages encryption certificate if you select the select certificates manually option, select the certificate to be used if the assertions sent by the identity provider must be encrypted service provider configuration manual entity id if you are completing a manual configuration, ask the saml service provider administrator for this setting assertion consumer service url saml service provider url that receives the assertion sent by the identity provider signature verification certificate upload the certificate to be used by the identity provider to verify the signature of incoming saml messages if no certificate is specified, the certificate embedded in the incoming saml message is used for signature verification encryption certificate upload the certificate to be used if the assertions sent by the identity provider must be encrypted if not certificate is specified, the assertions sent by the identity provider are not encrypted enable signature verification certificate status checking select this option to enable revocation checks for the signing certificate uses the configuration on the system > configuration > certificates > trusted client cas page enable encryption certificate status checking select this option to enable revocation checks for the encryption certificate uses the configuration on the system > configuration > certificates > trusted client cas page customize identity provider behavior override default configuration select this option to set custom behavior of the system saml identity provider for this sp instance if you select this option, the user interface displays the additional options listed next reuse existing nc (ivanti ) session this option cannot be enabled here if it is not selected for the sign in saml identity provider default settings accept unsigned authnrequest individual service providers can choose to accept unsigned authnrequest sign saml assertion saml assertion will be signed along with signing the saml response by default relay state saml relaystate attribute sent to the service provider in an identity provider initiated sso scenario if left blank, the relaystate value is the url identifier of the resource being accessed session lifetime suggest a maximum duration of the session at the service provider created as a result of the saml sso select one of the following options none the identity provider does not suggest a session duration role based suggest the value of the session lifetime configured for the user role customized if you select this option, the user interface displays a text box in which you specify a maximum in minutes sign in policy select the sign in url to which the user is redirected in a service provider initiated scenario the list is populated by the sign in pages configured in authentication > signing in > sign in policies the user is not redirected if he or she already has an active session and had authenticated through this sign in policy force authentication behavior in an service provider initiated scenario, the service provider sends an authnrequest to the identity provider if the service provider authnrequest includes the forceauthn attribute set to true and the user has a valid session, this setting determines how the identity provider responds select one of the following options reject authnrequest do not honor the saml sso request re authenticate user invalidate the user session and prompt for reauthentication this setting prevails over the ivanti session reuse setting user identity subject name format format of nameidentifier field in generated assertion select one of the following options dn username in the format of dn (distinguished name) email address username in the format of an e mail address windows username in the format of a windows domain qualified username other username in an unspecified format subject name template for generating the username that is sent as the value of the nameidentifier field in the assertion you may use any combination of available system or custom variables contained in angle brackets and plain text attribute statement configuration send attribute statements select this option if the saml sp requires additional attributes to be sent with saml assertions if you enable attribute statements, select one of the following configuration options use idp defined attributes send attributes based on the default settings for the system saml identity provider communication with all saml service providers customize idp defined attributes selectively configure the attributes that are sent for this particular peer saml sp attributes to be sent in saml attribute statements can be specified manually as name value pairs, or you can configure an option to fetch name value pairs from an ldap server (or you can specify both manual entries and ldap entries) if you select this option, configure the settings described next attribute name an ascii string friendly name a more readable friendly name for the attribute this is optional (an option included in the saml standard) attribute value the attribute value can be specified as a hard coded string, a custom variable, or a user attribute variable system conventions for specifying user and custom tokens and variables apply the value can be a combination of a string and a user or custom variable for example email \<customvar email> the value can also be a combination of user and custom variables and hardcoded text for example mydata=\<user>\<realm>\<customvar email> value type select single valued or multivalued a single valued attribute can be a combination of a string and a user or custom variable if there are multiple single valued attributes configured with the same attribute names, they are combined and sent as a multivalued attribute select multivalue if you want every individual token defined in the attribute value column to be sent as a separate attributevalue for example \<element ref="saml\ attributevalue" minoccurs="0" maxoccurs="unbounded"/> if the attribute value is given as \<user>mars\<realm>ivanti\<role> and the value type is marked as multivalued, then the values sent as part of attribute statement are sent as follows username realmname role note that only the tokens \['<>'] will be considered when processing a multivalued attribute marked the remaining data (for example mars, jupiter) is discarded specifying the token \<role> will send only one role to send all roles, specify the attribute value with the syntax \<role sep=","> if you specify \<role sep=","> as a single valued attribute, it is sent as a single string with "," separated roles if you specify \<role sep=","> as a multivalued attribute, each role is sent in a separate \<attributevalue> element encryption is set at the assertion level you cannot encrypt individual attributes directory server to fetch attribute name value pairs from an ldap server, complete the following settings directory server select the ldap server from the list you must add the ldap server to the authentication > auth servers list before it can be selected username for lookup enter a username template for ldap lookup the default is the variable \<username> the \<username> variable stands for the login credential the user entered when logging in the value can contain contextual characters as well as variables for substitution attribute name type an ldap attribute name, such as cn the attribute name is fetched from the ldap server and sent as saml attribute statements as part of a saml assertion friendly name a more readable friendly name for the attribute this is optional (an option included in the saml standard) with the ldap option, the saml idp sends attributes in the form configured on the backend ldap server if the ldap server returns an attribute value in multivalued form, then the saml attribute statement will also be in multivalued form configuring a saml sso resource policy for gateway mode deployments when deployed as a gateway in front of enterprise resources, the saml sso policy acts like other resource policies when deployed as a gateway, the saml sso communication can be configured as either identity provider initiated or service provider initiated the system maintains the session and uses its rewriting or pass through proxy features to render data to the user you use a saml sso resource policy when the protected resource supports saml sso and has been configured as a saml service provider to configure a saml sso resource policy select users > resource policies > web use the tabs to display the sso > saml page if your administrator view is not configured to show saml policies, click the customize button in the upper right corner of the page and select the sso and saml check boxes click new policy to display the configuration page complete the settings described in the following table save the configuration the following table lists the saml sso resource policy configuration guidelines settings guidelines name type a name for the policy description type a description that would be meaningful to other administrators resources specify the fully qualified domain name for the resources for which this policy applies these are the resources protected at the saml service provider roles select one of the following options policy applies to all roles to apply this policy to all users policy applies to selected roles to apply this policy only to users who are mapped to roles in the selected roles list make sure to add roles to this list from the available roles list policy applies to all roles other than those selected below to apply this policy to all users except for those who map to the roles in the selected roles list make sure to add roles to this list from the available roles list action select one of the following options use the saml sso defined below typically, this is the setting you use for a saml sso resource policy the system saml identity provider/saml service provider makes the sso request when a user tries to access a saml resource specified in the resources list do not use saml the system does not perform an sso request use this if there is a problem with the saml service provider and you want to allow access use detailed rules use this option to configure advanced rules saml sso details saml version select 2 0 saml sso type an administrator has the option to choose between idp (ics) or sp to initiate saml single sign on select the required saml sso type idp initiated ics (configured as identity provider) initiated saml sso sp initiated service provider initiated saml sso in rewriter mode service provider entity id select the service provider entity id the service provider entity ids listed here are configured on the authentication > signing in > sign in saml > identity provider > peer service provider pages cookie domain enter a comma separated list of domains to which the system sends the sso cookie rewrite response from sp select this option if the saml service provider generates http responses that require user/browser action, such as submission of a form, javascript execution, redirection to a different location, and other similar behavior if you select this option, the system rewrites the http responses sent by the saml service provider and sends them to the user configuring service provider initiated saml sso ivanti supports sp initiated saml sso when ics is configured as idp in gateway mode ics uses the existing user session in generating saml assertion for the user for sso in sp initiated sso, the sequence is as follows a user logs into ics and clicks bookmark (sp initiated saml sso resource) ics sends the request to sp sp responds with saml authnrequest to ics as the user is not authenticated to sp ics posts saml assertion to sp sp sends the resource to ics ics rewrites the resource and provides access to the user to configure a saml sso resource policy select users > resource policies > web use the tabs to display the sso > saml page if your administrator view is not configured to show saml policies, click the customize button in the upper right corner of the page and select the sso and saml check boxes click new policy to display the configuration page in the saml sso details section, select saml sso type as sp initiated complete other settings described in the following table save the configuration configuring a saml external applications sso policy when deployed to support access to external resources (for example, public cloud resources), the system does not have to be a gateway to user access the user can access the external resource directly, and the traffic does not flow through the device to enable saml sso in these deployments, you configure the system as a saml identity provider to correspond with the external saml service provider, and you configure a saml external applications sso policy to determine the users and resources to which the saml sso experience applies to configure a saml external apps sso resource policy select users > resource policies > web use the tabs to display the sso > saml external apps sso page if your administrator view is not configured to show saml policies, click the customize button in the upper right corner of the page and select the sso and saml check boxes click new policy to display the configuration page complete the settings described in the following table click save changes the following table lists the saml sso external applications policy configuration guidelines settings guidelines name type a name for the policy description type a description that would be meaningful to other administrators resources specify the fully qualified domain name for the resources for which this policy applies these are the resources protected at the saml service provider roles select one of the following options policy applies to all roles to apply this policy to all users policy applies to selected roles to apply this policy only to users who are mapped to roles in the selected roles list make sure to add roles to this list from the available roles list policy applies to all roles other than those selected below to apply this policy to all users except for those who map to the roles in the selected roles list make sure to add roles to this list from the available roles list action select one of the following actions use the saml sso defined below typically, this is the setting you use for a saml sso resource policy the system saml identity provider makes the sso request when a user tries to access to a saml resource specified in the resources list do not use saml the system does not perform an sso request use this if there is a problem with the saml service provider and you want to allow access use detailed rules use this option to configure advanced rules saml sso details service provider entity id select the service provider entity id the service provider entity ids listed here are configured on the authentication > signing in > sign in saml > identity provider > peer service provider pages configuring a saml 2 0 acl web policy to configure the system as a policy enforcement point, you must create a saml acl web policy to configure a saml acl web policy in the admin console, select users > resource policies > web use the tabs to display the access > saml acl page if your administrator view is not configured to show saml policies, click the customize button in the upper right corner of the page and select the saml acl check box on the saml access control policies page, click new policy complete the settings described in the following table click save changes on the saml access control policies page, order the policies according to how you want the system to evaluate them keep in mind that once the system matches the resource requested by the user to a resource in a policy's (or a detailed rule's) resource list, it performs the specified action and stops processing policies the following table lists the saml acl web policy settings setting description name type a name for the policy description type a description that would be meaningful to other administrators resources specify the fully qualified domain name for the resources for which this policy applies these are the resources protected at the saml service provider roles select one of the following options policy applies to all roles to apply this policy to all users policy applies to selected roles to apply this policy only to users who are mapped to roles in the selected roles list make sure to add roles to this list from the available roles list policy applies to all roles other than those selected below to apply this policy to all users except for those who map to the roles in the selected roles list make sure to add roles to this list from the available roles list action select one of the following options use the saml access control checks defined below the system performs an access control check to the specified url using the data specified in the saml access control details section do not use saml access the system does not perform an access control check use detailed rules use this option to configure advanced rules saml access control details saml version 2 0 if you select manual, complete the saml access control details if you select metadata, select the policy decision point to use if the metadata option is disabled, you have not defined or uploaded a metadata file on the system > configuration > saml page saml web service url completed automatically if using metadata if you configure manually, enter the url of the access management system saml server for example, enter https //hostname/ws saml web service issuer enter the hostname of the issuer, typically the hostname of the access management system you must enter unique string that the saml web service uses to identify itself in authorization assertions authentication type select one of the following options none do not authenticate the system username authenticate using a username and password enter the username and password that the system must send the web service certificate attribute authenticate using a certificate signed by a trusted certificate authority if you have more than one certificate installed on the system, use the drop down list to select which certificate to send to the web service user identity subject name type specify which method the system and saml web service should use to identify the user select one the following options dn send the username in the format of a dn (distinguished name) attribute email address send the username in the format of an e mail address windows send the username in the format of a windows domain qualified username other send the username in another format agreed upon by the system and the saml web service subject name use variables to specify the username to the saml web service or, enter static text you must send a username or attribute that the saml web service will recognize device issuer enter a name that uniquely identifies the saml authority, such as the device hostname maximum cache time you can eliminate the overhead of generating an authorization decision each time the user requests the same url by indicating that the system must cache the access management system's authorization responses enter the amount of time the system should cache the responses (in seconds) ignore query data by default, when a user requests a resource, the system sends the entire url for that resource (including the query parameter) to the saml web service and caches the url you can specify that the system should remove the query string from the url before requesting authorization or caching the authorization response example implementing saml 2 0 web browser sso for google apps this example shows how to implement saml 2 0 web browser sso for google apps topology when deployed to support access to external resources (for example, public cloud resources), the system does not have to be a gateway to user access the user can access the external resource directly, and the traffic does not flow through the device you configure the system as a saml identity provider to correspond with the external saml service provider, and you configure a saml sso external applications policy to determine the users and resources to which the saml sso experience applies when you configure the saml identity provider, some settings are necessary to support either identity provider initiated or service provider initiated sso the documentation for the configuration steps makes note of these settings regardless, you configure the saml identity provider to support both identity provider initiated and service provider initiated sso the following figure illustrates the flow of network communication in a service provider initiated sso scenario ivanti connect secure as a saml identity provider (peer mode) in a service provider initiated sso scenario 1 the user clicks a link to access a resource 2a the service provider sends an http redirect status code (http 302) to the user the saml request and all other saml details are sent as url parameters in the url location header 2b the user sends an http get request to the identity provider the saml request and all other saml details are sent as url parameters if the user already has a session with the identity provider, steps 2 1 and 2 2 are skipped 2 1 if the user does not have a session, the identity provider sends an authentication challenge to the user 2 2 the user enters sign in credentials 3a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 3b the user sends the form to the service provider 4 the external resource is delivered to the user's browser the following figure illustrates the flow of network communication in an identity provider initiated sso scenario ivanti connect secure as a saml identity provider (peer mode) in an identity provider initiated sso scenario 1 the user authenticates to the identity provider 2 the identity provider returns a portal page with links to external resources 3 the user clicks a link for an external resource 4a the identity provider sends a successful status code (http 200 ok) to the user with a form in the html body 4b the user sends the form to the service provider 5 the external resource is delivered to the user's browser configuring the google apps saml service provider to configure the google apps saml service provider log into the google apps control panel the url is similar to the following https //www google com/a/cpanel/acmegizmo com https //www google com/a/cpanel/acmegizmo com https //www google com/a/cpanel/acmegizmo com click advanced tools in the menu bar click the set up single sign on (sso) link to display its configuration page, as shown in the following figure configure the saml service provider settings as described in the following table click save changes the following figure depicts the google apps advanced tools sso the following table lists the google apps sso configuration settings guidelines enable single sign on select this option sign in page url type the url of the system saml sso service the url formed with the primary host fqdn for saml has the following form https //samlhostname/dana na/auth/saml sso cgi for example https //i5 lab ivanti com/dana na/auth/saml sso cgi the url formed with the alternate host fqdn for saml (to support ivanti /nc session detection) has the following form https //i5 lab ivanti net/dana na/auth/saml sso cgi sign out page url we recommend using the url for the sign in page for the realm associated with the system saml identity provider users who already have a session will be directed to the sign in page and can decide whether to log out from the system or not the default sign in url has the form https //fqdn for example https //i5 lab ivanti com/ change password url we recommend using the url for the sign in page for the realm associated with the system saml identity provider the system provides password management capabilities for some back end auth servers (such as ad, ldap, or local auth) when implemented, the password management capabilities are accessed from the sign in page the default sign in url has the form https //fqdn for example https //i5 lab ivanti com/ verification certificate click browse and select the device certificate then click upload and ensure that the certificate is saved use a domain specific issuer select this option network masks do not select configuring the ivanti connect secure saml identity provider you configure the system saml identity provider settings to match the google apps saml service provider settings to configure the saml identity provider settings select system > configuration > saml > settings to complete the global saml settings these settings apply to all of your saml deployments the following figure shows an example of saml global settings the following figure depicts the saml global settings select authentication > signing in > sign in saml > identity provider to configure saml identity provider settings these settings apply to all of your deployments where the device is a saml identity provider the following figure depicts the saml identity provider settings docid\ w8him5gdqsv75bqt xjlr shows an example of saml identity provider settings the following figure depicts the saml identity provider settings on the saml sign in identity provider page, click add sp and complete the settings for communication with google apps google apps does not publish metadata, so the configuration is manually configured the google saml service provider uses the http post binding and takes usernames in e mail address format the following figure shows an example of sp settings for google apps the following figure depicts the peer sp settings select users > resource policies > web > saml external apps sso and complete settings for the external applications policy that controls the users and the resources that can use the sso implementation the following figure shows an example of an saml external applications sso policy for google apps the following figure depicts the saml external apps sso policy settings verifying the google apps saml sso deployment access a google docs or google apps resource as a non admin user to verify the solution works as expected use a browser plugin such as http watch if you want to trace the saml communication between the saml service provider and saml identity provider to verify service provider initiated sso make sure you are not logged into the device or google open a web browser and open a location on google docs or google apps google apps redirects you to the sign in page to authenticate log in the access management framework processes the authentication request, performs host checking rules and role mapping rules if authentication is successful, the system redirects you to the google docs or google apps location you had requested to verify ivanti /nc session detection for service provider initiated sso make sure you are not logged into the device or google use ivanti or vpn tunneling client to create an ssl vpn connection open a web browser and open a location on google docs or google apps you should not have to authenticate to access the google docs or google apps location to verify identity provider initiated sso use the system admin console to create a bookmark to a location on google docs or google apps as a user, log in to the device click the bookmark link to the google docs or google apps location you should not have to authenticate to access the google docs or google apps location using saml authncontext class variables in role mapping and web acl rules this topic describes how to use security assertion markup language (saml) authncontext class variables in access management framework rules for information about saml authncontext class variables, refer to the saml 2 0 oasis authn context specification configuring saml authncontext class variables in the authentication server configuration in deployments where the system is a saml service provider (saml sp), you can configure the saml sp to request authentication context classes from the saml identity provider (saml idp) the saml sp includes these in the requestedauthncontext element in response, the saml idp sends the context data along with the authentication results the system stores the authncontext data in the session cache you can use the system variable named samlauthncontextclass to create rules based on authncontext in role mapping and resource policies to specify the saml authncontext class variables in the saml sp configuration select authentication > auth servers create a new saml server configuration or edit one you have already created figure docid\ w8him5gdqsv75bqt xjlr shows the saml server configuration page red boxes highlight the configuration elements for authncontext classes select the authncontext classes that you want to request from the saml idp, and select a comparison method this feature supports all authentication context classes described in the saml 2 0 oasis authn context specification the comparison method values are defined in the saml 2 0 oasis core specification you should specify the same values that have been configured on the saml idp if none is specified in the saml idp configuration, the implicit default is exact save the configuration the following figure depicts the authentication server configuration page configuring a role mapping rule based on a saml authncontext class variable you can use role mapping rule custom expressions to include authncontext class data as a factor in role determination to configure role mapping rules select users > user realms create a new realm or edit a realm you have already created click new rule to display the configuration page select custom expression and click update to redisplay the configuration page with the controls related to custom expressions the following figure shows the configuration page click expressions to display the server catalog dialog box the next figure shows the dialog box select samlauthncontextclass, select an operator, and click insert expression edit the expression template to match the authncontextclassref data expected from the saml idp save your changes to the variable expression and return to the rule configuration page select the expression, roles for the rule, and the stop option (if desired) save your changes to the rule configuration and return to the realm configuration page reorder the rules if necessary save the realm configuration the following figure depicts the role mapping rule configuration page the following figure depicts the server catalog expressions and variables configuring a web acl policy rule based on a saml authncontext class variable you can use the resource policy detailed rules configuration to include authncontext class data as a factor in resource access determinations this example shows how to use a saml authncontext class variable in web acl detailed rules in the same manner, you can use the authncontext class variable in detailed rules for other resource policies to configure a resource policy select resource policies > web > web acl create a new policy or edit a policy you have already created click the detailed rules tab for the policy click new rule to display the detailed rules configuration page the following figure shows the detailed rule configuration page under conditions, select samlauthncontextclass, select an operator, and click insert expression edit the condition expression template to match the authncontextclassref data expected from the saml idp select a rule action and resources to which the rule applies, and save your changes to return to the policy configuration page reorder the rules if necessary save the configuration the following figure depicts the detailed rule configuration page using policy tracing logs to verify the saml authncontext class variable is used in rules you can use policy tracing logs to verify your configuration to create a policy trace log select troubleshooting > user sessions > policy tracing to display the configuration page specify the username, realm , and source ip address if you know it if you provide the source ip address, the policy trace log can include events that occur before the user id is entered into the system select the events to trace click start recording initiate the action you want to trace, such as a user sign in click view log to display the policy trace results log click stop recording when you have enough information the following figure shows policy trace results the highlighted entries show the data populated to the samlauthncontextclass system variable, as well as the role mapping rule that was matched investigating a "no valid assertion found in saml response" error problem description saml is a time sensitive protocol the time based validity of a saml assertion is determined by the saml identity provider if the saml identity provider and saml service provider clocks are askew, the assertion can be determined invalid, and authentication fails environment in the scenario described here, the system is deployed as a saml service provider in a saml 2 0 deployment symptoms in this scenario, the following error is returned to the user after the user has submitted credentials to the saml identity provider saml transferred failed please contact your system administrator detail failure no valid assertion found in saml response " cause to investigate the error select maintenance > troubleshooting > monitoring > debug logs to display the debug log configuration page, shown in the following figure the following figure depicts the debug log page turn debug logging on, set debug log detail level to 10, and event codes to saml reproduce the action that results in the error in this case, user access to the resource associated with the saml service provider that prompts the user to submit credentials to the saml identity provider click save debug log the console displays the save as dialog box save the file to a location your local host or a location that you can access when sending mail the file is an encrypted file, so do not try to open it and analyze it yourself e mail the debug log to support center support center will use the file to diagnose the issue in the debug log, the following log lines indicate issues with the time based validity of the assertion verifysubjectconfirmationdata assertion has expired processconditions assertion has expired \[notonorafter condition failed] processconditions assertion is not yet valid \[notbefore condition failed] these log lines indicate a clock sync issue only if failure of the time based validity check is unexpected the same log lines might appear in the debug log to indicate an assertion has expired as expected solution we recommend you use ntp to ensure the clocks are synchronized and that you set an allowed clock skew value that accommodates any expected or permissible skew properly synchronized clocks avoid unexpected failure to configure ntp select system > status to display the system status page next to system date & time , click edit to display the date and time page specify the settings for the same ntp server used by the saml identity provider save your configuration to be ndcpp compliant, ntp update interval needs to be limited to 60 minutes this is to avoid the potential drift becoming too excessive to set the allowed clock skew value select authentication > auth servers select the saml authentication server you want to configure to display its configuration page specify a number of minutes in the allowed clock skew to accommodate any expected or permissible skew save your configuration