This Series of Articles Nuts & Bolts of SAML in ServiceNow describes the core components of SAML and how they facilitate the SAML Authentication for SingleSignOn in Servicenow. Please dont forget to bookmark this article if you want to easily access it in future.
Article # 1: The Bigger Picture
SAML stands for Security Assertion Markup Language, which is an XML standard for exchanging authentication and authorization data between security domains. (find additional details in Wikipedia SAML 2.0).
Before looking at the bigger picture of SingleSignOn in ServiceNow, you need to know the following SAML components from ServiceNow's perspective.
1. SAML Participants/Actors
2. SAML Protocols
3. SAML AuthnRequest
4. SAML Assertions
5. SAML Bindings
Note:- As you read through the functionality of each SAML component, keep in mind that the last section of the article explains how these components work together for implementing SSO.
SAML Participants/Actors
SAML Assertion party or Identity Provider: The party which creates SAML assertions, example: Okta, OneLogin etc.
SAML Relying party or Relying Party: The party which depends on SAML assertions, which is ServiceNow
SAML Protocols
Imagine SAML Protocols as a mechanism that allows ServiceNow to request for a SAML Assertion from an Identity Provider. There are 6 such protocols are defined in the SAML Core specification. You can find more information about all the protocols in the link: SAML Protocols. Out of the 6 protocols, the protocol that is used in servicenows SAML 2.0 is the Authentication Request Protocol. Where we define a <AuthnRequest> message that causes a <Response> to be returned containing one or more assertions about the user who is trying to login. Typically the <AuthnRequest> is issued by a Service Provider with the Identity Provider returning the <Response> message.
SAML AuthnRequest
An AuthnRequest is sent by the Service Provider (ServiceNow) to the Identity Provider in order to get a SAML Assertion as a response. Below is an example of how an AuthnRequest looks like. The integration then URL-encodes the <samlp:AuthnRequest> element and sends it as the SAMLRequest URL parameter.
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_1" Version="2.0" IssueInstant="2004-12-05T09:21:59Z" AssertionConsumerServiceIndex="0">
<saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
</samlp:AuthnRequest>
SAML Assertion
An Assertion is a set of security statements about a subject created by an Asserting Party (AP), in most common use cases it is about an individual. I am not going to dig deep into the SAML Assertion now, so just assume that a SAML assertion has all the details to tell the Service Provider (ServiceNow) about the authenticated user. Below is an example of how a SAML Assertion looks like.
SAML Bindings
SAML does not define its own transport protocols instead of existing transport such as HTTP transport can be used to transmit SAML messages, SAML Binding specifies exact semantics to transmit SAML messages via other protocols. For an example a encode SAML message within HTTP POST request body or encode SAML message within the body of SOAP message etc.
Most of these bindings assume two roles called Requester and Responder, Requester is the entity requesting some services by sending a SAML request message and Responder is the entity that supply required information as a SAML response. Most of the cases Requester is identical to the Service Provider (SP) concept and Responder is identical to Identity Provider (IdP) but there are few exceptional cases as well.
following are the SAML Bindings: HTTP Redirect Binding, HTTP Post Binding, HTTP Artifact Binding, HTTP SOAP Binding, HTTP PAOS Binding.
SSO in ServiceNow uses two bindings in specific HTTP Redirect Binding, HTTP POST Binding.
HTTP Redirect Binding: HTTP redirect enables SAML protocol messages to be transmitted within URL parameters. It enables SAML requestors and responders to communicate by using an HTTP user agent as an intermediary.
HTTP POST Binding: HTTP POST enables SAML protocol messages to be transmitted within an HTML form by using base64-encoded content. It enables SAML requestors and responders to communicate by using an HTTP user agent as an intermediary.
Bigger Picture !!
Putting all the above components together, below is the flow Diagram of SAML. ( Below Flow Diagram will pop up in various places in this article series. )
The user attempts to access a resource on the ServiceNow. However they do not have a current login session on Servicenow and their federated identity is managed by their Identity Provider say, Google. They are sent to the IdP to log on and the IdP provides a SAML web SSO assertion for the user's federated identity back to the ServiceNow. For SSO in ServiceNow, the HTTP Redirect Binding is used to deliver the SAML message to the IdP and the HTTP POST Binding is used to return the SAML message containing the assertion to the ServiceNow
1. The user tries to login to ServiceNow and the user doesn't have a valid login session. The requested resource URL is saved in local state information that can be used across the web SSO exchange.
2. ServiceNow sends an HTTP redirect response to the browser (HTTP status 302 or 303). The Location HTTP header contains the destination URI of the Sign-On Service at the identity provider together with a message encoded (AuthnRequest) as a URL query variable named SAMLRequest.
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="1">
<saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>The query string is encoded using the DEFLATE encoding. The browser processes the redirect response and issues an HTTP GET request to the IdP's Single Sign-On Service with the SAMLRequest query parameter. The local state information (or a reference to it) is also included in the HTTP response encoded in a RelayState query string parameter. https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
The SSO service processes the <samlp:AuthnRequest> 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<tt> and <tt>RelayState URL parameters
3. The Single Sign-On Service determines whether the user has an existing logon security context at the identity provider that meets the default or requested (in the ) authentication policy requirements. If not, the IdP interacts with the browser to challenge the user to provide valid credentials.
4. The user provides valid credentials and a local logon security context is created for the user at the IdP.
5. After collecting the required login credentials, the SSO service validates the request and responds with a document containing an XHTML form. This XHTML form contains the SAML Assertion.
<formmethod="post"action="https://instance.service-now.com/navpage.do" ...>
<input type="hidden" name="SAMLResponse" value="response ..." />
<input type="hidden" name="RelayState" value="token ..." />
...
<input type="submit" value="Submit" />
</form>Below is how a SAML Assertion looks like
<samlp:Responsexmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="s2cdc74f37f923e26fe1aeec42b70a93d24230334f" InResponseTo="90AA6073F01567BFB0DF194F596314E2" Version="2.0" IssueInstant="2010-04-29T23:21:51Z" Destination="https://dloomac.service-now.com/navpage.do">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://idp.ssocircle.com</saml:Issuer>
<samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:SAML:2.0:status:Success"></samlp:StatusCode>
</samlp:Status><saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="s23e536bfc51b8487d4d3299dec162d9c2e338823b" IssueInstant="2010-04-29T23:21:51Z" Version="2.0">
<saml:Issuer>http://idp.ssocircle.com</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
</Signature><saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="http://idp.ssocircle.com" SPNameQualifier="https://dloomac.service-now.com/navpage.do">david.loo@service-now.com</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData InResponseTo="90AA6073F01567BFB0DF194F596314E2" NotOnOrAfter="2010-04-29T23:31:51Z" Recipient="https://dloomac.service-now.com/navpage.do" /></saml:SubjectConfirmation>
</saml:Subject><saml:Conditions NotBefore="2010-04-29T23:11:51Z" NotOnOrAfter="2010-04-29T23:31:51Z">
<saml:AudienceRestriction><saml:Audience>https://dloomac.service-now.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions><saml:AuthnStatement AuthnInstant="2010-04-29T23:21:51Z" SessionIndex="s2dbf89ab99001e0e8cdaed67266d9d4b21b968a04">
<saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
6. The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the ServiceNows Assertion Consumer Service. The SAMLResponse value is base64 decoded and inflated to reveal the XML document in SAML Assertion. The login script extracts the XML value from the //Subject/NameID element and uses it to lookup 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.
7. User is authenticated in ServiceNow and the access to the resource is granted.
References:
SAML 2.0 concepts : Login (AuthnRequest) process flow
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
What avenues are open then for a web app (down stream of ServiceNow) where the user, already authenticated to SN, could be "SSO'd" into the other platform.
here is the scenario (below)
The goal would be an SSO like experience with JIT provisioning when a user from GROUP E clicks on a link they would be given access to the New LMS (nLMS). JIT would give the nLMS info to put them in the correct company and group to then permit access to the content.
Groups A&B are the same, however they are coming from a different SN instance. but in both cases it would SN acting as the "IDP".
