Single Sign-On

Single Sign-On provides the ability for users to gain access to multiple enterprise systems with a single login. A single login saves time for users, and simplifies their work, because they no longer have to stop to login again at every gateway to an application/portal/enterprise system.

Two options are available for Single Sign-On (SSO):

• SSO - Delegated Authentication
• SSO - SAML

SSO - Delegated Authentication

Single Sign-On (SSO) allows for the delegated authentication of platform Users against a corporate database. With SSO, users have a single username and password that provides access to applications which support SSO.

Using SSO allows an organization to validate their users in their own secured environment. This means you can implement you own authentication methods (such as a database or LDAP Directory) to authenticate a user.

How it Works

After a user is validated against the customer’s environment, the user is logged into the platform.

Scope

SSO is limited to user authentication and does NOT include authorization. Users must be active in the platform. Teams, Roles and other permissions must also be maintained.

It is the responsibility of the corporate System Administrator/IT Staff to develop and implement a Web service that can accept and respond to the SSO web service calls made by the platform servers.

Actions

When a User logs in, the following actions take place to authenticate the user in both the platform and in your organization's systems. This table lists the actions taken by the User, the platform and your organization's web service. See Web Service for more information.

User does...	Platform does...	Your Organization's Web Service does...
1. On User Login	Validate that: User is Active SSO is Enabled
2.	Make a Web Services call to the organization's Web service, requesting authorization. Include these parameter in the call: username password originatingIp Note: originatingIp is the IP address that originated the login request. This could be useful to restrict access based on the user’s location. The Web Service must be implemented in a way that the platform is able to access it.
3.		Validate the passed information and return either "Authenticated" or "Failure".
4.	On Authenticated response, generate a new User Session. On Failure, notify the user.

Making a Web Service Call

Use the URL and port number provided under the Single Sign-On Settings Section to make a SOAP request to authenticate the users. SSO Request and SSO Response are predefined by the platform. These request and response are conducted via SOAP messaging.

Web Services Message Format

Request

SSO SOAP Request sent from the platform is as follows:

<?xml version="1.0" encoding="UTF-8" ?>
	<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
		<soapenv:Body>
			<LJAuthenticate xmlns="urn:authentication.soap.ws.longjump.com">
				<username>jim@abc.com</username>
				<password>sales</password>
				<originatingIp>1.2.3.4</originatingIp> 
			</LJAuthenticate>
		</soapenv:Body>
	</soapenv:Envelope>

Response

SSO SOAP Response expected by the Platform is as follows:

<?xml version="1.0" encoding="UTF-8" ?>
	<soapenv:Envelope   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
		<soapenv:Body>
			<LJAuthenticateResponse xmlns="urn:authentication.soap.ws.longjump.com">
				<Status>Authenticated</Status>
			</LJAuthenticateResponse>
		</soapenv:Body>
	</soapenv:Envelope>

Implement SOAP in Your Corporate Environment

Consider the following best practices when implementing delegated authentication single sign-on for your organization:

• Your organization’s implementation of the Web service must be accessible by the platform servers. This means you must deploy the Web service on a server typically in your DMZ.
• Namespaces, element names, and capitalization must be exact in SOAP requests. Wherever possible, generate your server stub from the WSDL to ensure accuracy.
• For security reasons, you should make your Web service available by SSL only. You must use an SSL certificate from a trusted provider, such as Verisign or Thawte.
• The platform sends you the originatingIp in the web service call it makes to your servers. You can use this information to restrict access based on the user’s location.
• You must map your organization’s internal usernames and the platform's usernames. If your organization does not follow a standard mapping, you may be able to extend your user database schema (for example, Active Directory) to include the platform username as an attribute of a user account. Your authentication service can then use this attribute to map back to a user account.
• We recommend that you do not enable single sign-on for the system administrator’s profile. If your system administrators are single sign-on users and your single sign-on server has an outage, they have no way to log in to the platform. System administrators should always be able to log in to the platform so they can disable single sign-on in the event of a problem.

SSO - SAML

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between security domains. The Service Provider must enroll with an Identity Provider and obtain an Issuer URL.

How it Works

First, Single Sign-On Settings are configured for SAML in the platform, then a link to the AgileApps Cloud platform is created in the corporate website/portal. Note: the link can be named or branded in any way, as specified by the Service Provider.

Users logged into a corporate website/portal can click the link and are then automatically logged into the AgileApps Cloud platform, without requiring additional authentication.

For example, an employee of ABC Company logs into the corporate website, which includes a link to the AgileApps Cloud platform on the landing page. The user clicks the link and is automatically logged in, without requiring a second login.

Enable SSO in the Platform

Users with the System Administrator role can enable Single Sign On

Single Sign On must be enabled for each user, individually. This is typically performed when the user account is created in the platform. Learn more: Add a User

To configure Single Sign-On:

1. Click Settings > Administration > Single Sign-On
2. Click the [Edit] button
3. In the Single Sign-On Settings section, complete the following information:

   Implementation Type

   Choose from Delegated Authentication or SAML

   Delegated Authentication

   • In the Configuration section, complete the following information:

   • Specify the URL of the authentication server running in your environment (abc5.abc.com:8080)
   • Note that the URL and Port number must be specified using a Fully Qualified Domain Name or an IP address. Secure HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) protocol is used to access this URL.
   • If you do not have this information available, contact your IT department or System Administrator.

   SAML

   • In the Configuration section, complete the following information:

   Version

   SAML Version

   • Choose from Version 1.0 or Version 2.0

   Issuer

   The Issuer URL acts as a identity provider, which is an entity that authenticates a user or maintains user's credentials. The Identity Provider issues a URL, which is used to contact this provider during the login process.

   • Syntax:The URL and Port Number must be specified using a FQDN or an IP address, for example:

   • www.abc.com:9090
   • 192.168.1.10
   • abc.def.com

   User Id Type

   Determines the type of identifier

   • Choose from UserId or Federated Id, where:

   • UserId is the Record Identifier of the user that is logged in
   • Federated Identity acts as a user's authentication across multiple IT systems or organizations. Learn more: Federated Identity.

   User Id Location

   Specifies an attribute tag that defines the location of the User Id

   • Choose from Subject or Attribute

   Issuer Certificate

   Issuer certificate is used to sign and verify SAML messages. Requires a valid x509 issuer certificate.

   • Choose one of the following options:

   • Paste the Issuer Certificate in the text area

   • Navigate to the Issuer Certificate section, then select and load a file containing the Issuer Certificate

4. Enable Single Sign-On for each User, via Add a User

Guidelines

• The System Administrator can decide to enable some users for SSO and disable SSO for other users. In this case, users with SSO enabled will be validated against their corporate environment and users with SSO disabled will be validated against the platform.
• SSO cannot be turned off if there exists at least one user who has SSO enabled from the user profile. If the System Administrator tries to disable SSO under this condition, a warning is displayed.
• If SSO is disabled, and the System Administrator tries to enable SSO for a user, the System Administrator is asked to enable SSO, and provide a valid SSO URL
• When disabling SSO for a User, the administrator is asked to use Reset Password for the user. This is to ensure that this user receives a valid password for login.

Restrictions

• Username in the platform should be same as the username in your organization's environment
• These password-related options are not allowed:

• Reset Password
• Change Password
• Forgot Password - a Message will be shown prompting the user to contact their organization's system administrator

• When adding a new user, the Welcome email message will not contain a password.
• SSO can be turned on/off at the user level, if the System Administrator has granted the user rights to change this setting
• Single Sign-On is not available for the Self-Service Portal application