Dapresy SSO Overview

Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications. The service authenticates the end user for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session.


Dapresy’s SSO solution enables you to integrate Dapresy authentication with your internal system via federated login. So when we talk about Dapresy SSO we are talking about federation between Dapresy and external organization. A federated identity management system provides single access to multiple systems across different enterprises.


Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a person in each application and presents that application with a token that says, "this person is domain\johndoe or johndoe@example.com."No password is required for the user to log in to each system. Because of the trust between the two systems, the target application accepts this token and authenticates the user.


Currently, Dapresy supports Active Directory Federation Services (AD FS) with SAML protocol.


Using the System

Active Directory Federation Services (AD FS) with SAML protocol


Overview

AD FS is a standards-based service that allows the secure sharing of identity information between trusted business partners (known as a federation) across an extranet. When a user needs to access a Web application from one of its federation partners, the user's own organization is responsible for authenticating the user and providing identity information in the form of "claims" to the partner that hosts the Web application (in this case Dapresy). The hosting partner uses its trust policy to map the incoming claims to claims that are understood by its Web application, which uses the claims to make authorization decisions. 


AD FS is Microsoft's implementation of the WS-Federation Passive Requestor Profile protocol (passive indicates that the client requirements are just a cookie- andJavaScript-enabled Web browser). AD FS implements the standards based WS-Federation protocol and Security Assertion Markup Language (SAML).


SAML for Web browser SSO involves three parties. There is (1) a user, (2) an identity provider (IdP), and (3) a cloud application service provider (SP). The IdP stores information about the user in a database, like Active Directory. The user connects to the SP and attempts to authenticate. If the SP recognizes the username, it delegates authentication to the IdP. The IdP validates the user against its identity database. It then sends an SAML assertion about that user to the service provider. The SP then gives the user access to the application.


Supported AD FS versions

Dapresy currently supports the following AD FS versions:


  • ADFS 1.0 - Windows Server 2003 R2 (additional download)
  • ADFS 1.1 - Windows Server 2008 and Windows Server 2008 R2
  • ADFS 2.0 - Windows Server 2008 and Windows Server 2008 R2 (download fromMicrosoft.com)
  • ADFS 2.1 - Windows Server 2012
  • ADFS 3.0 - Windows Server 2012 R2
  • ADFS 4.0 - Windows Server 2016Azure ADFS is also supported.


Supported SAML Protocols 

Dapresy currently supports the following SAML protocols:

  • SAML v1.0
  • SAML v2.0


Pre-Requirements

In order to use the AD FS solution with Dapresy, you need to have the following:

• An AD FS server up & running in your internal network

• Ability to support SAML protocol (v1.0 or v2.0)

• Have valid FederationMetadata file with vendor certificate


Parties

In this process there are two parties:

• Dapresy as a Service Provider (SP)

• External organization as Identity Provider (IdP)


Claims

In basic configuration, Dapresy only needs NameID claim. 

This claim should contain the user’s username.In order to authenticate your user in a Dapresy project, the username in NameID claim must be the same as username created in Dapresy. 


Dapresy SSO Proxy 

Dapresy SSO proxy is a web server that is responsible for receiving client’s IdP initiated requests. These requests have been validated on this proxy by checking the token in an SAML message with the client’s certificate. If the request is valid, then proxy will authenticate the user in Dapresy database. If all is fine, then it will redirect the user to the requested Dapresy project. 


Dapresy SSO proxy provide an endpoint where IdP should POST request. Every Dapresy client will get their unique SSO proxy endpoint.


Process Flow

This is the SSO process flow:

1. User accesses the host application and clicks to go to a Dapresy project

2. The host app authenticates the user in internal network

3. If the user is authenticated in internal database, then the host app will initiateIdP login to Dapresy SSO proxy via SAML protocol

4. SSO proxy receives the IdP request and validates the token in SAML message

5. If the token is OK, then the username is loaded from NameID claim and the authentication request is sent to Dapresy’s Web application

6. Dapresy’s app authenticates the username by checking it in the database

7. If the authentication is valid, then SSO proxy will redirect the user into the Dapresy project



How to Configure It

In order to enable federated SSO between your company and Dapresy, the following steps must be completed:

1. Provide your valid FederationMetadata.xml file that contains your SAML signing certificate and all configuration from your end.

2. Dapresy will configure your unique SSO proxy with your metadata file andsend you Dapresy’s metadata file. This file contains Dapresy certificate,AssertionConsumerService URL (which is URL of SSO proxy endpoint) and all other necessary configurations.

3. When you receive Dapresy’s metadata file, you need to create a relying party trust in your ADFS server by using our metadata file.Once all these items are done, federated SSO is ready for use.