A quick-start guide for implementing Single Sign-On / Authentication using SAML 2.0 for a Web Server Application

Introduction

The 10Duke Identity Provider (IdP) API offers a quick and simple means of providing users access to cloud and corporate applications using a single identity. You can connect any application to the 10Duke IdP and each time a user tries to authenticate, the 10Duke IdP will verify their identity and send back to your application the information it requires.

This tutorial covers implementing authentication in your application with the 10Duke Identity Provider by using SAML 2.0.

Terminology / Roles

  • The Identity Provider
    This is the IdP server that grants access tokens and identity tokens for users that it has authenticated.

  • The User Agent
    This is the browser and e.g. desktop applications and mobile applications.

  • The User
    The person who is authenticated by the Identity Provider. When using OAuth 2.0, client application can also access resources owned by the authenticated user via APIs of the Identity Provider.

  • The Service Provider
    In SAML 2.0, this is the name of the client that will delegate authentication to the 10Duke IdP.

API / Service endpoints

Item URL ​​(relative,​ ​prepend​ ​environment​ ​base​ ​URL)
Authorization code /

Step 1. Register your application with the 10Duke IdP

We will need to collect some basic information about your application to create a new client.

Please send the below details to info@10Duke.com and we will respond by email:

  • Your app name e.g. “myapp”

  • The SAML 2.0 metadata document. If your service provider does not have one, we need at least the following details for the service provider:

    • Issuer Name

    • Assertion Consumer Service (ACS) URL

    • Information if the consumer expects SAML response or assertions contained by the response to be signed

Step 2. Get the SAML configuration details

Once you have provided us with your application details, we will provide you with the SAML metadata required for communicating with the IdP.

Step 3. Send authentication request

When the client application needs to authenticate the user, it will need to send the user to the IdP that handles user authentication on behalf of the client application.

  • You will need to build a SAML authentication request (AuthnRequest)

  • In your application, you will then need to redirect to the authentication endpoint of the 10Duke IdP, giving the authentication request as the SAMLRequest parameter

Step 4. Handle SAML response

Once the 10Duke IdP has authenticated the user, it will send the user agent back to the Assertion Consumer Service (ACS) URL of your application, with SAMLResponse containing information of the authenticated user.

  • You need to parse the SAML response and verify signature
  • You can read user id from the Subject NameID field of the response
  • You can other user attributes from the AttributeStatement of the response

Please see https://wiki.shibboleth.net/confluence/display/OS30/Home for example OpenSAML Java and C++ client libraries.

Step 5. Confirming delegation of authentication to the 10Duke IdP

Congratulations! If you have integrated your test application to the IdP correctly you should now be able to sign-in to your test application and see it delegate authentication to the IdP (watch your browser urls change as it does this) and then return you, as a logged-in user, back to your test application.

If you run into any issues, please raise them on StackOverflow, tag them “10Duke”, and we’ll respond asap.