Skip to main content

Identity Provider

User attempts to access a protected resource directly on the service provider (SP) site without being logged on.

The user does not have an account on the service provider (SP) site, but does have account managed by Swapcard (IdP). The service provider (SP) sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user’s browser via HTTP POST.

About IdP Initiated​

Flow

Scenario​

  1. Bill the user : Hey Jimmy, show me that web page
  2. Jimmy the SP : Hey, I'm not sure who you are yet. We have a process here so you go get yourself verified with Bob the IdP first. I trust him.
  3. Bob the IdP : I see Jimmy sent you here. Please give me your credentials.
  4. Bill the user : Hi I'm Bill. Here are my credentials.
  5. Bob the IdP : Hi Bill. Looks like you sign on successfully.
  6. Bob the IdP : Hey Jimmy. This guy Bill successfully sign-in and here's some additional information about him. You do whatever you want from here.
  7. Jimmy the SP : Ok cool. Looks like Bill is also in our list of known guests. I'll let Bill in.

Technical explanation​

  1. The user requests access to a protected service provider (SP) resource. The request is redirected to the identity provider (IdP) to handle authentication.

  2. If the user is already logged, the IdP server sends an HTML form back to the browser with a SAML request for authentication from the IdP. The HTML form is automatically posted to the SP.

  3. If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on.

  4. The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP. SAML specifications require that POST responses be digitally signed.

  5. If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.

Flowchart

Configuration​

To setup the SSO, the customer will need to provide Swapcard with a metadata file in XML format or a link to their metadata that contains the following:

  • Entity id
  • Certificate
  • Assertion endpoints

Entity id​

An identifier that used to identify the issuer of a SAML request, response, or assertion.

The syntax of such an identifier is a URI of not more than 1024 characters in length. It is RECOMMENDED that a system entity use a URL containing its own domain name to identify itself.

Example :

https://sp.example.com

Certificate​

  • The certificate used for signing purpose
  • The certificate used for encryption purpose

Example :

<X509Certificate>MIIERTCCAq2gAwIBAgIJAKmtzjCD1+tqMA0GCSqGSIb3DQEBCwUAMDUxMzAxBgNV
...5hL6/bKUWnNMurQNGrmi/jvqsCFLDKftl7ajuxKjtodnSuwhoY7NQy8=</X509Certificate>

Assertion endpoints​

The asssertion consumer service endpoint, where the SAML response is POST

Example :

https://sp.example.com/acs

SAML Response​

The SAML response contains :

  • Email
  • FirstName
  • LastName
  • Organization
  • PhotoUrl
  • SecondaryEmails