JOSSO.orgCommunity Documentation

Chapter 7. Authentication Setup

7.1. Set Up Directory-based Authentication
7.2. Set Up Integrated Windows Authentication
7.3. Set Up Two-Factor Authentication

Directory-based authentication is built onto the bind operation of the LDAP protocol. It authenticates the client to the server using this operation. The server will typically check the password against the userPassword attribute in the named entry.

An Identity Provider setup for directory-based authentication will, instead of verifying the supplied user credentials locally, delegate this task to an external directory through an LDAP Bind request. If the LDAP Bind operation is successful the user will be considered authenticated, whereas in the opposite case the authentication will fail.

Using Directory-based authentication allows you to leverage a corporate identity silo, such as Microsoft's Active Directory, for centralized user authentication. Therefore, the time to deployment decreases, given that the burden of setting up an authoritative source for user and entitlement information to be consumed by the Single Sign-On system is unnecessary.

Directory-based Authentication is represented in the figure below :

From the Palette, click "Directory Service" in the "Authentication" drawer.

Click on and drag the "Directory Service" element to the preferred location within the Diagram Canvas.

In the "New Directory Service Definition" window, enter the name of the Directory Service element to be added to the Identity Appliance Diagram.

Field Descriptions

Field

Description

Name

The unique identifier of the Directory-based Authentication element.

Description

A descriptive text for the Directory-based Authentication element.

Initial Context Factory

The fully qualified class name of the InitialContextFactory implementation.

This defaults to the Sun LDAP provider implementation com.sun.jndi.ldap.LdapCtxFactory.

Provider URL

Enter the LDAP URL for the LDAP Directory Server.

This defaults to "ldap://localhost:389", thus expecting a directory server listening on the standard port available in the same server that both JOSSO and the identity appliance execute.

Perform DN search

Determines whether the distinguished name of the user entry will be used as the user identifier. The user's distinguished name will then be used to retrieve the user's roles. If this option is not selected, the user identifier will be set to the common name attribute of the user entry.

LDAP Security Policy

The LDAP Security Policy mechanism to use.

Select "RFC Draft" to enable LDAP Security Policy support based on the specifications contained in the draft RFC titled draft-behera-ldap-password-policy-09. For more information see : http://tools.ietf.org/html/draft-behera-ldap-password-policy-09

Select "None" to disable LDAP Security Policy support.

Security Principal

Enter the security principal for authentication of the caller to the service.

This defaults to "uid=admin,ou=system", the default for OpenLDAP.

Security Credential

Enter the credential for the security principal that will be passed on to authenticate the caller to the service.

The semantics of this field depend on the chosen authentication mechanism, as described below.

Retype Security Credential

Re-enter the security credential supplied in the upper field.

Security Authentication

Determines what authentication mechanism will be used to authenticate the caller to the service.

Available options are "None" for anonymous binding, "Simple" for password-based authentication and "Strong" for authentication using X.509 client certificates.

On the "Lookup" screen, you can determine how user and role entries are to be retrieved. This is required in order to access identity data responding to arbitrary schemas. The forced migration of user data to a product-specific user schema is avoided, allowing you to re-use existing identity silos independently of user data structure.

Field

Description

User DN

Enter the Distinguished Name (DN) that will be used as the context for user searches. This defaults to "ou=People,dc=my-domain,dc=com".

Principal UID (User Identity) Attribute ID

Enter the LDAP attribute name that holds the distinctive identifier of the user. This defaults to "uid".

Search Scope

Enter the search strategy used to query user and role entries in the target LDAP directory.

The default is "Subtree".

Setting the search scope to "Base" queries within the specified contexts.

Setting the search scope to "One" will cause LDAP queries to search only the immediate children of the LDAP object corresponding to the DN for users and roles.

Setting it to "Subtree" will query the entire LDAP directory subtree below the search baseDN for users and roles.

Setting the search scope to "Children" will cause LDAP queries to search one level below all direct children of the base entry.

Click on OK to confirm Directory Service element creation.

Click on Cancel to abort Directory Service element creation.

Integrated Windows Authentication uses the security features of Windows clients and servers. Unlike Basic or Digest authentication, it does not initially prompt users for a user name and password. The current Windows user information on the client computer is supplied by the browser through a cryptographic exchange.

By enabling Integrated Windows Authentication for an Identity Provider, a user with an existing session against a trusted Windows Domain will be automatically logged in when accessing a service provider's resources.

Integrated Windows Authentication is represented in the figure below :

From the Palette, click "Windows Domain" in the "Authentication" drawer.

Click on and drag the "Windows Domain" element to the preferred location within the Diagram Canvas.

In the "New Windows Domain Definition" window, enter the name of the Windows Domain Authentication element to be added to the Identity Appliance Diagram.

Field Descriptions

Field

Description

Name

The unique identifier of the Windows Domain Authentication element.

Description

A descriptive text for the Windows Domain Authentication element.

Protocol

Enter the GSSAPI (Generic Security Services Application Program Interface) mechanism to use for negotiating a security token with the selected Windows domain controller.

The default is "Kerberos".

Setting the protocol to "Kerberos" enables the use of the Kerberos protocol when negotiating service tickets with a Windows domain controller.

Setting the protocol to "NTLM v2", enables the use of the NTLM v2 protocol when negotiating service tickets with a Windows domain controller.

Windows Domain

The identifier of the trusted Windows domain controller.

Service Class

The service that is being accessed, such as HTTP.

Set this to the protocol used by JOSSO for servicing requests.

Host

The computer name for the computer that hosts the service.

Set this to the fully qualified hostname used by JOSSO for servicing requests. By default JOSSO is bound to 'localhost'.

Port

Port is optional and only used for nonstandard port configurations.

Set this to the port used by JOSSO for servicing requests. By default JOSSO listens on port 8081.

Service Name

The Service Name portion of the SPN.

Domain Controller

The fully qualified hostname where the trusted Windows domain controller is servicing requests.

Configure Kerberos

Select to choose an automatically generating Kerberos configuration.

Keytab file

Select to upload the keytab file from the local file system. The supplied keytab file will be used to authenticate the Identity Provider against the trusted Windows domain controller.

Click on OK to confirm Windows Domain element creation.

Click on Cancel to abort Windows Domain element creation.

Two-factor authentication is a security process in which the user provides two means of identification; one of which is typically a physical token, such as a card, and the other typically something memorized, such as a security code. In this context, the two factors involved are sometimes spoken of as "something you have" and "something you know".

JOSSO supports out-of-the-box two-factor authentication, creating a secure, easy-to-use solution for organizations that require SSO. JOSSO supports a wide variety of services including: Tomcat, JBoss, Apache Web Server, IIS, Liferay, Weblogic and Alfresco; as well as cloud services like Google Apps, Salesforce and SugarCRM. WiKID, for its part, supports Radius, LDAP and TACACS+ in addition to having an API. WiKID Software tokens run on Linux, Mac, Windows, iPhone, Android, J2ME and others.

Fundamentally, WiKID Strong Authentication works like this: a user selects the domain they wish to use and enters the PIN into their WiKID two-factor client. It is encrypted with the WiKID Server's public key - assuring that only that server can decrypt it with its private key. If the server can decrypt the PIN, and it is correct and the account is active, it generates the one-time passcode (OTP) and encrypts it with the client's public key. The user then enters their username and the OTP into whatever service they are using, (a VPN, for example) which forwards it to the WiKID Server for validation.

WiKID Two-Factor Authentication is represented in the figure below :

From the Palette, click "Windows Domain" in the "Authentication" drawer.

Click on and drag the "Windows Domain" element to the preferred location within the Diagram Canvas.

In the "New WiKID Definition" window, enter the WiKID client configuration used by the associated Identity Providers to offer strong authentication.

Field Descriptions

Field

Description

Name

The unique identifier of the WiKID Two-Factor Authentication element.

Description

A descriptive text for the WiKID Two-Factor Authentication element.

Server Host

Fill with the IP address or host name for your WiKID server.

Server Code

Enter the Server Code of your WiKID domain.

Certificate Authority Store

Select to upload the Certificate Authority Keystore of the WiKID server from the local file system. The supplied keystore file will be used to authenticate and decrypt messages coming from the WiKID server.

Certificate Authority Password

The passphrase required to open the Certificate Authority Store.

WiKID Client Store

Select to upload the keystore of the JOSSO network client server from the local file system. The supplied keystore file will be used to authenticate and encrypt requests to the WiKID server.

WiKID Client Password

The passphrase required to open the WiKID Client keystore.

Click on OK to confirm WiKID Authentication element creation.

Click on Cancel to abort WiKID Authentication element creation.