--- sourceDocument: Australia Platform security sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/platform-security Release : - australia ft:locale : - de-DE ft:publication_title : - Australia Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Login (AuthnRequest) process flow # Login (AuthnRequest) process flow {#ariaid-title1} * Freigeben Version: Australia * * Aktualisiert 12. März 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 Minuten Lesedauer SAML 2.0 specifies a Web Browser SSO Profile that involves exchanging information among an identity provider (IdP), a service provider (SP), and a principal (user) on a web browser. The identity provider can be any SSO service offering SAML authentication services (for example SSOCircle). The service provider is always an instance. The message flow begins with a request for a secured resource at the service provider. ## Request the target resource at the SP The principal requests a target resource at the service provider: https://instance.service-now.com/ The instance checks the request to see if the SAMLRequest and RelayState URL parameters are present. If they exist, the user has already validated with the IdP and can skip steps 2--6. ## Issue AuthnRequest to Identity Provider The instance constructs an `AuthnRequest` to be sent to the IdP using the `SAMLRequest` value. The instance also constructs and sends a `RelayState` URL parameter value. The `RelayState` token is an opaque reference to state information maintained at the service provider. The value of the `SAMLRequest` parameter is the deflated and base64 encoded value of the `` element: https://sp.example.com/SAML2 The integration then URL-encodes the `` element and sends it as the `SAMLRequest` URL parameter. The SSO service processes the `` element by URL-decoding, base64-decoding and inflating the request, in that order. It then performs a security check. If the user does not have a valid security context, the IdP identifies the user by prompting for login credentials. If the user is already logged in, the IdP simply responds with the `SAMLResponse and RelayState` URL parameters (see step 3). ## Respond with an SAMLResponse and RelayState After collecting the required login credentials, the SSO service validates the request and responds with a document containing an XHTML form: ... The value of the `RelayState` parameter comes from this step. The value of the `SAMLResponse` parameter is the base64 encoding of the following `` element: http://idp.ssocircle.comhttp://idp.ssocircle.com ... david.loo@service-now.comhttps://dloomac.service-now.comurn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ## Validate SAMLResponse The `SAMLResponse` value is base64 decoded and inflated to reveal the XML document in step 3. The login script extracts the XML value from the `//Subject/NameID` element and uses it to look up an existing user in the User table. The login script also extracts the session ID from the `//AuthnStatement/@SessionIndex` element and stores it for the `LogoutRequest`.