Skip to main content

Service Provider

User attempts to login and access a Community or an Event in the Service Provider (SP) Swapcard.

The user must have an already existing account in the Service Provider (SP) Swapcard and also an account managed by the Identity Provider (IdP) on customer end.

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.

Heads up!

Swapcard does not allow profile creation via SAML, Swapcard only provides access to already created users in the platform.

About SP 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 to 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.

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
  • Existing Swapcard Application

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 uses 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 assertion consumer service endpoint, where the SAML response is POST

Example :

https://sp.example.com/acs

SAML Response​

Swapcard can only allow existing users to Login into the platform using SAML SSO. No profile creations are supported via SAML. The SAML response from the customer IDP must have the user email as an Attribute. The exact email must be used in the profile of the user trying to login to Swapcard.

<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">user@test.com</saml:AttributeValue>
</saml:Attribute>

Customize your Swapcard Login Page​

The following parameters can be customize :

  • The text inside the button (one text per locale).
  • Remove the original email form.

Login Page