Single Sign-On

From ISV Support Wiki

Single Sign-On (Redirected from Single Sign On)
Jump to: navigation, search

Settings > Administration > Single Sign-On

File:Lock-tiny.gif

  • The Single Sign-On option is managed by a Service Provider admin
  • This feature is disabled by Default
Learn more: Tenant Configuration Options

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.

Contents

Simplified SOAP Protocol for Single Sign-On

The platform's implementation of Single Sign-On uses simple SOAP messages sent over an HTTP connection. The resulting protocols are simple enough to be implemented in a minimum amount of time, making it easy for enterprises to integrate platform services into their existing operations.

Best Practices

Consider the following best practices when implementing 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.

Enabling SSO in the Platform

File:Lock-tiny.gif

Users with the System Administrator role can enable Single Sign On 

Single Sign On must be enabled for each user, individually--typically 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, choose one of the available options:
  4. Fill in the settings for the choice you made (described in the sections that follow)
  5. Enable Single Sign-On for individual Users.
    Learn more: 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

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... Platform... Your Organization's Web Service...
1. Log into the platform Validate that:
  • User is Active
  • SSO is Enabled
2. Make a Web Services call to the organization's

Web service, requesting authorization. Include these parameters 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.

Enabling Delegated Authentication

  1. Click Settings > Administration > Single Sign-On
  2. Click the [Edit] button
  3. For Single Sign-On Settings, choose Delegated Authentication
  4. Fill in the Delegated Authentication Settings:
    • 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.
  5. Click [Save]

Setting up Communications with the Authentication Server

For a successful handshake with the platform, the authentication server needs a certificate. If you are using a self-signed certificate, it needs to be loaded into the cacert keystore file in the platform's {installed_JDK}/jre/lib/security folder. Otherwise, you get an SSL error.

To load the certificate into the keystore:

  1. Make sure that the JAVA_HOME environment variable points to the JRE in an installed JDK.
    Check the configuration in these three locations:
    • installation.properties
    • configure.pl installation script
    • scripts/longjump
    Learn more: Platform Installation Files
  2. Load the certificate using the keytool -import command/
    The default password is "changeit".
    Learn more: Java Tutorial: Importing a Certificate

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>

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 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 platform, without requiring additional authentication.

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

Enabling SAML

  1. Click Settings > Administration > Single Sign-On
  2. Click the [Edit] button
  3. For Single Sign-On Settings, choose SAML
  4. Fill in the SAML Settings
  5. Click [Save]

SAML Settings

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 Id 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

Pass Through Authentication

Pass Through Authentication (PTA) lets a user go straight to the platform from an organization's web page or application, without having to log in again.

How it Works

As part of an enterprise application, the user would like to visit a page hosted on the platform, without having to log in to the platform to see it. To accomplish that goal, the application sends a small SOAP message to the platform, in an HTTP request.

That message contains the information needed to log into the platform. Data in it is passed to an authentication server, which sends back a message saying that authentication has succeeded or failed, after which the user is directed to the appropriate page.

The URL of the Authentication Server and the URLs of the pages to visit in the event of success or failure are configured in the platform's Single Sign-On Settings.


Actions

User... Platform... Your Organization's Web Service...
1. Provides a web page or application
2. Visits the page or application
3. Clicks a link to go to a platform page
4. Passes data to the platform's PTA service in the SOAP payload
5.
  • Receives data in the SOAP payload:
  • Session ID (optional, but desirable)
  • Login ID
  • Passes data to the Authentication server
6. Receives a success- or failure-report from the Authentication Server
7. Redirects the user to the appropriate page.

Enabling Pass Through Authentication

  1. Click Settings > Administration > Single Sign-On
  2. Click the [Edit] button
  3. For Single Sign-On Settings, choose Pass Through Authentication
  4. Fill in the Pass Through Authentication Settings:
    Third party Authentication Service URL
    Location of the authentication service. The platform uses this URL to authenticate the USER, passing the appropriate pay load in the HTTP request.
    Success page URL
    The page the platform sends the user to when authentication succeeds:
    • If not specified, the default destination is the platform's home page.
    Error page URL
    The page the platform sends the user to when authentication fails:
    • If not specified, the default destination is the platform’s Login-error page.
    • Can be overridden dynamically by the Authentication Server
  5. Click [Save]

Message Formats

Initial Message Sent to the Platform

This message format needs to be delivered to the platform by the Application or web page.

Method
POST
URI
https://{domain}/networking/passThroughAuth
<?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">
                        <sessionID>...</sessionID>
                        <loginID>...</loginID>
                </LJAuthenticate>
        </soapenv:Body>
</soapenv:Envelope>

where:

sessionID
The session ID of the user on the organization's website. Optional. It is passed on to the authentication service, so the authentication service can make use of it.
loginID
The user's login name on the platform--typically in the form of an emails address.

Messages Sent Between the Platform and Authentication Server

These message formats need to be processed and/or delivered by the Authentication Server.

Message sent from the platform to the Authentication Server
The Authentication Service reads this request and authenticates the user.
Method
POST
URI
Configured in the Single Sign-On Settings
<?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">
                        <sessionID>...</sessionID>
                        <originatingDomain>...</originatingDomain>
                        <originatingIp>...</originatingIp>
                        <loginID>...</loginID>
                </LJAuthenticate>
        </soapenv:Body>
</soapenv:Envelope>
where:
originatingDomain
Name of the Domain the request originally came from (e.g. wwww.paaspartout.com)
originatingIp
IP Address of the domain the request originally came from (e.g. 10.20.30.40)
sessionID
Passed on from the original request
loginID
Passed on from the original request
Authentication-Succeeded response
This response is sent when authentication succeeds.
<?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>
                        <loginID>userLogin@Login.com</loginID>
                </LJAuthenticateResponse>
        </soapenv:Body>
</soapenv:Envelope>
Authentication-Failed response
This response is sent when authentication fails.
<?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>NOT_AUTHETICATED</status>
                        <loginID>userLogin@Login.com</loginID>
                        <redirectOnErrorURL>http://www.location.com/somePage</redirectOnErrorURL>
                </LJAuthenticateResponse>
        </soapenv:Body>
</soapenv:Envelope>
where:
redirectOnErrorURL
URL of the next page the user sees. (Overrides the Single Sign-On settings.)
Retrieved from "http://isv.platformatyourservice.com/wiki/Single_Sign-On"
Views
Categories
[−] Help
[+] Settings
[+] Designer
[+] Customizing
[+] Tools and APIs
[+] Sys Admin Guide
[+] Installation
[+] Learn More
[+] Glossary
[+] FAQs
Personal tools