Single Sign-On Workflow

With the new release of Starmind we switched from a Reverse-Proxy approach for the Service Provider to a more "detached" Single Sign-on architecture. The Service Provider is not acting as a Reverse-Proxy anymore, instead the Service Provider is a standalone component only handling the SAML 2.0 protocol. This architecture does simplify the configuration for a network because SSO is not bound to a certain Service Provider and doesn't relay on special DNS entries.

Single Sign-on Workflow

Step Description
1 Initial request by the user to the basedomain of the network e.g.
2 The App-Server will initiate the Single Sign-On process with the Service Provider (SP) if the client is missing a valid Auth-Token. The Auth-Token is sent as part of the HTTP Authorization Header (Bearer token).
The client is redirected (HTTP 302) to the SP including the correct ENTITY_ID for this network e.g.
3 The Service Provider can locate the correct metadata based on the provided ENTITY_ID and initiate the authentication.
The client is redirected (HTTP 302) to the Identity Provider including a signed SAML Authentication Request.
4 The IdP performs the authentication with the client and forwards the result (SAMLAuthResponse) as part of the body via HTTP POST to the Service Provider. If the authentication was successful the SAMLAuthResponse includes information such as givenname, surname, email-address and a unique identifier for the user.
5 The Service Provider will decode the SAMLAuthResponse, extract all relevant information and repack it in an encrypted / signed TOKEN.
6 The encrypted / signed Token is sent via HTTP POST to the registered callback of the App-Server e.g.
7 The App-Server will decrypt the Token, validate the signature and process the extracted information.
8 Respond with HTTP 200 and the Auth-Token if the verification was successful.