Difference between revisions of "Delegated Authentication"

From LongJump Support Wiki
imported>Aeric
imported>Aeric
 
(25 intermediate revisions by the same user not shown)
Line 1: Line 1:
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.  
With delegated authentication, you use your own server to validate platform Users against a corporate database or an LDAP Directory. Users can then use a single username and password to access all of their applications--as long as they support delegated authentication.


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.  
===Scope ===
Delegated Authentication 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.


===Enabling Pass Through Authentication===
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 web service calls made by the platform servers.
#Click '''Settings > Administration > Single Sign-On'''
#Click the '''[Edit]''' button
#For ''Single Sign-On Settings'', choose Delegated Authentication.
#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 [http://en.wikipedia.org/wiki/FQDN 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.'''
#Click '''[Save]'''
 
===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.
===How Delegated Authentication Works===
When a User logs in, their identity is authenticated in both the platform and in your organization's systems. The following diagram shows the process:
:[[File:SSO-DA.png]]


====Actions====
This table describes the actions taken by the User, the platform, and your organization's [http://en.wikipedia.org/wiki/Web_service Web Service].
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 [http://en.wikipedia.org/wiki/Web_service Web Service] for more information.


{| border="1" cellpadding="5" cellspacing="0"
:{| border="1" cellpadding="5" cellspacing="0"
!User does...
!
!Platform does...
!User
!Your Organization's Web Service does...
!Platform
!Your Organization's Web Service
|-
|-
|1. On User Login ||Validate that:
|1. || Log into the platform || Validate that:
:* User is Active
:* User is Active
:* SSO is Enabled
:* SSO is Enabled
|  
|  
|-
|-
|2. ||Make a Web Services call to the organization's
|2. || || Make a Web Services call to the organization's Web service, requesting authorization.  
Web service, requesting authorization. Include  
Include these parameters in the call:
these parameter in the call:
:<syntaxhighlight lang="java" enclose="div">
username
username
password
password
originatingIp
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.
</syntaxhighlight>
''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".
|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.||
|4. || || On Authenticated response, generate a new User Session. On Failure, notify the user.||
|}
|}


====Making a Web Service Call====
===Enabling Delegated Authentication===
#Click '''Settings > Administration > Single Sign-On'''
#Click the '''[Edit]''' button
#For ''Single Sign-On Settings'', choose '''Delegated Authentication'''
#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 [http://en.wikipedia.org/wiki/FQDN 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.''
#*Choose whether or not to Enable Single Sign-On for individual [[User]]s.
#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 <tt>{installed_JDK}/jre/lib/security</tt> folder. Otherwise, you get an SSL error.
 
To load the certificate into the keystore:
# Make sure that the <tt>JAVA_HOME</tt> environment variable points to the JRE in an installed JDK.<br/>Check the configuration in these three locations:
#:* <tt>installation.properties</tt>
#:* <tt>configure.pl</tt> installation script
#:* <tt>scripts/longjump</tt>
#: ''Learn more:'' Platform [[Installation Files]]
# Load the certificate using the <tt>keytool -import</tt> command/
#: The default password is "changeit".
#: ''Learn more:'' [http://download.oracle.com/javase/tutorial/security/toolsign/rstep2.html 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.
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.
Line 55: Line 68:
===Web Services Message Format===
===Web Services Message Format===
;Request:SSO SOAP Request sent from the platform is as follows:
;Request:SSO SOAP Request sent from the platform is as follows:
<syntaxhighlight lang="xml" enclose="div">
:<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8" ?>
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
Line 69: Line 82:


;Response:SSO SOAP Response expected by the Platform is as follows:
;Response:SSO SOAP Response expected by the Platform is as follows:
<syntaxhighlight lang="xml" enclose="div">
:<syntaxhighlight lang="xml" enclose="div">
<?xml version="1.0" encoding="UTF-8" ?>
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Envelope  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
Line 79: Line 92:
</soapenv:Envelope>
</soapenv:Envelope>
</syntaxhighlight>
</syntaxhighlight>
===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.

Latest revision as of 18:58, 19 September 2012

With delegated authentication, you use your own server to validate platform Users against a corporate database or an LDAP Directory. Users can then use a single username and password to access all of their applications--as long as they support delegated authentication.

Scope

Delegated Authentication 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 web service calls made by the platform servers.

How Delegated Authentication Works

When a User logs in, their identity is authenticated in both the platform and in your organization's systems. The following diagram shows the process:

SSO-DA.png

This table describes the actions taken by the User, the platform, and your organization's Web Service.

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.
    • Choose whether or not to Enable Single Sign-On for individual Users.
  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>