Single Sign-on (SSO) technologies for the Domino Web Server

(1)

Single Sign-on (SSO)

technologies for the Domino

Web Server

Jane Marcus

(2)

(3)

Agenda

● SSO using LTPA

● LTPA SSO configurations with Domino and WebSphere ● Windows Single Sign-on for Web Clients (SPNEGO) ● Extending the Domino Web Server using DSAPI

(4)

Fewer password prompts, fewer passwords in general

● We need single sign-on (SSO) because:

High administrative cost for managing passwords.

Users can't remember a lot of passwords.

Password prompts are annoying.

Many “different” passwords leads to lower security.

● If we use cryptographic mechanisms instead of passwords, we can

(5)

Lightweight Third Party Authentication (LTPA)

● LTPA is one of IBM's SSO solutions.

● Architecture allows interoperability with other SSO solutions.

● Web scenarios use an encrypted browser cookie.

LtpaToken : original format

(6)

SSO Using LTPA Overview (Part 1)

● User browses to a Domino URL

(7)

SSO Using LTPA Overview (Part 2)

● Domino authenticates the user.

Behind the scenes:

• Domino returns an LTPA token (browser cookie) that represents the logged in user.

(8)

SSO Using LTPA Overview (Part 3)

● User can browse to URLs on Domino and other SSO servers without

repeating login steps.

Browser automatically sends LtpaToken in HTTP requests.

Single sign-on works because SSO servers honor the LtpaToken to represent the logged in user.

(9)

Configuration Shared By Domino SSO Servers

● SSO document configured in Domino directory.

Document is encrypted for participating servers.

Document contains SSO keys used to create/verify the LTPA cryptographic tokens.

(10)

SSO Configuration Document Name vs Token Name

● Historically the SSO document by default named “LtpaToken”.

● The SSO document can be configured to have any arbitrary name.

(11)

Where to Find the SSO Configuration Document

● If Internet Site configuration is turned on in the server document

(recommended):

Internet Sites view contains the SSO configuration document.

One server can have different SSO configurations for its various URLs.

● If Internet Site configuration is turned off in the server document:

(12)

Agenda

● SSO using LTPA

(13)

LTPA SSO with WebSphere and Domino

● User can login first to WebSphere, or can login first to Domino.

LTPA token created by Domino will be honored by WebSphere, and vice versa.

Servers must share the same SSO cryptographic keys.

LtpaToken Browser

(14)

Sharing cryptographic keys with WebSphere

● Create keys in WebSphere

Export to file, import into Domino.

WebSphere options to automatically regenerate keys usually are impractical in SSO configuration with Domino.

● Domino “Import WebSphere LTPA keys” option

(15)

Name Mapping often is needed

● The user's LTPA token contains the user's distinguished name.

● User's Domino distinguished name found on Domino database ACLs:

CN=Walter Neff/O=Renovations

● User's distinguished name in WebSphere's LDAP directory:

(16)

Directory choices: where do you want to make

directory modifications for SSO?

● The LTPA token will need to contain the user's WebSphere LDAP

distinguished name.

● Name mapping using Domino person records:

Store user's WebSphere LDAP distinguished name

✔ OR

● Name mapping using WebSphere's LDAP directory:

Store user's Domino distinguished name

Configure Domino directory assistance to LDAP

(17)

SSO name mapping using Domino directory

● Configure Domino to create the LTPA token containing the user's

WebSphere name:

• CN=Walter Neff,CN=users,DC=ad,DC=east,DC=renovations,DC=com

● SSO document the user's Person record:

(18)

SSO name mapping using WebSphere's directory

● Configure WebSphere's LDAP directory to contain the user's Domino

name in an LDAP attribute (eg. “NotesDN”):

• CN=Walter Neff,O=Renovations

● SSO document Directory Assistance to LDAP:

(19)

Agenda

● SSO using LTPA

(20)

SSO Using LTPA (Part 1)

(21)

Windows Single Sign-on for Web Clients

Avoid the user name and password challenge!

(22)

Windows Single Sign-on for Web Clients

(SPNEGO)

● User acquires Kerberos credentials when starting Windows.

Windows verifies user's password.

Password never travels over the wire.

● SSO technology leveraging the Windows credentials sometimes called

by these names:

SPNEGO

“Integrated Windows Authentication” for the Windows Intranet

Windows login info

(23)

SPNEGO protocol used by browsers

● Protocol used to authenticate a user to an HTTP server.

Simple and Protected gssapi NEGOtiation

(24)

Windows and Domino SPNEGO/Kerberos

● Many setup steps to be done by the Active Directory administrator

using Windows tools.

Domino is assigned a Windows service name (SPN)

● Logged in user can acquire a Kerberos ticket for the Domino server.

Windows creates the Kerberos ticket.

The Kerberos ticket identifies:

• Domino Windows service name

• User's Kerberos name

● SPNEGO-aware browsers know how to

(25)

Domino and WebSphere SPNEGO

implementations return an LTPA token to the

browser

● User logs in to Windows.

● User starts browser and browses to Domino URL.

(26)

Domino and WebSphere SPNEGO

implementations return an LTPA token to the

browser

● User logs in to Windows.

● User starts browser and browses to Domino URL.

SPNEGO/Kerberos used to authenticate to Domino.

Domino returns LTPA token to facilitate SSO to other servers.

(27)

Name Mapping is required

● The Kerberos ticket contains the user's Kerberos name

[email protected]

● User's Domino distinguished name found on Domino database ACLs:

CN=Walter Neff/O=Renovations

● User's distinguished name in Active directory used with LTPA:

CN=Walter

Neff,CN=users,DC=ad,DC=east,DC=renovations,DC=com

● (recommended) Set up name mapping using Directory Assistance to

Active Directory

See

(28)

Configure SPNEGO/Kerberos at Domino

● Lots of Window setup, and the Domino Windows server must run as a

Windows service.

(29)

Domino LTPA vs Domino SPNEGO/Kerberos

● LTPA solution (Domino challenges for user password):

Supports Internet deployment: client browser can be located anywhere.

All supported platforms for Domino servers and web clients.

• Servers in same DNS domain.

● SPNEGO/Kerberos solution (Windows challenges for user password):

Intranet deployment only! Does not work across a firewall.

Supported only on Domino Windows servers, in Windows domain with Active Directory.

Tested with Windows browser clients. **Requires browser configuration.

(30)

Agenda

● SSO using LTPA

(31)

DSAPI

● You can write a C program to handle Domino web server events.

Lotus C API reference provides the DSAPI specification.

You write and build the DSAPI C code into a library (e.g. Windows dll).

Your DSAPI filter can handle authentication and any other HTTP event.

● You install the DSAPI library onto your Domino server.

● You configure Domino HTTP to load the DSAPI library on web server

(32)

DSAPI authentication filter

● Your DSAPI library can handle authentication events:

Your program registers an authentication filter at HTTP startup.

Domino will call your program when there is a request to access resources for which the user must be authenticated.

• Your C program could call a third party system, or prompt the user to login and verify the credentials.

• Outcome of a successful DSAPI authentication must provide Domino with the user's name (usually Domino distinguished name format).

● After successful DSAPI authentication, the web server may be

configured to provide an LTPA token.

● Example Windows DSAPI authentication filter:

(33)

Questions

Press *1 on your telephone to ask a question.

IBM Lotus Support page

(34)

Legal Disclaimer

The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

References in this publication to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.