Exploring Advanced Authentication Methods in Novell Access Manager

Exploring Advanced Authentication Methods in Novell® Access Manager™

Chris Van Den AbbeeleSolution Manager Identity Security Risk [email protected] Origin

© Novell, Inc. All rights reserved.2

Who is Atos Origin ?

Atos Origin is an international information technology services company. Its business is turning client vision into results through the application of consulting, systems integration and managed operations. The company's annual revenues are EUR 5,8 billion and it employs over 50,000 people in 40 countries. Atos Origin is the Worldwide Information Technology Partner for the Olympic Games and has a client base of international blue-chip companies across all sectors. Atos Origin is quoted on the Paris Eurolist Market and trades as Atos Origin, Atos Worldline and Atos Consulting.


Who is Atos Origin ?


Agenda

• Taking authentication to the Cloud • Local authentication mechanisms

– Static Pasword, One-time Password

– Novell® Access Manager Theory of Operations

• Trust-based authentication mechanisms – X509 (certificate) authentication

– Kerberos authentication

• Internet-based authentication protocols– Liberty, Shibboleth, OpenID, CardSpace

Taking Authentication to the Cloud


The Login Process

• Identification: – Identify yourself: Who are you?– Examples: jdoe, A172945, certificate...

• Authentication: – prove that you are who you say you are– Examples: password, private key (certificate),..

• Authorization:– Are you authorized.– Examples:

> Are you part of this group? Do you have this role?> Do you have that attribute value?


Outsourcing Authentication

• Applications with internal user/password store

• Authentication outsourced to local LDAP directory

• Authentication outsourced to a trusted source: Kerberos, X509

• Authentication outsourced using Internet protocolsSAML and co.

• Authentication and Authorization outsourced:Information Cards / Cardspace

Local AuthenticationNovell® Access Manager™

Theory of Operations


Browser

Identity Server

Access Gateway

Web Servers

LDAP(username/password)

42

41

5

3

7

6

Secu

rity

LDAP Store

Theory of Operations(Username / password authentication)


Secu

rityBrowser

Identity ServerLDAP Store

Access Gateway

Web Servers


7



Secu

rityBrowser


Access Gateway

Web Servers


1



Identity Server

Secu

rityBrowser

LDAP Store

Access Gateway

Web Servers


2


2


Secu

rityBrowser


Access Gateway

Web Servers

LDAP(username/password)3



Secu

rityBrowser

Identity Server

LDAP Store

Access Gateway

Web Servers


4

4

SAML artifact A SAML artifact is a eight byte number drawn from a random sequence. (*)

(*) http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-05.doc


http://www.oasis-open.org/committees/security/docs/draft-sstc-bindings-model-05.doc


Secu

rityBrowser


Access Gateway

Web Servers

5

SAML assertion A SAML assertion is a package of information including issuer and subject, conditions and advice, and/or attribute statements, and/or authentication statements and/or other statements. (*)


(*) http://www.oasis-open.org/committees/download.php/21265/draft-hodges-HowToLearnSAML-01.html

http://www.oasis-open.org/committees/download.php/21265/draft-hodges-HowToLearnSAML-01.html


http://www.oasis-open.org/committees/download.php/21265/draft-hodges-HowToLearnSAML-01.html


Browser

Identity Server LDAP Store

Access Gateway


7

6

Secu

rity



Data Flow (simplified)

1. The user requests access to a resource protected by the Access Gateway.

2. The Access Gateway redirects the user to the Identity Server, which prompts the user for authentication according to the authentication “contract” of the requested URL.

3. The Identity Server verifies the username and password against an LDAP directory (Novell® eDirectory™, Active Directory, or Sun ONE).

4. The Identity Server returns an authentication success to the browser and the browser forwards the resource request to the Access Gateway.

5. The Access Gateway verifies that the user is authenticated and retrieves the user’s credentials from the Identity Server.

6. The Access Gateway uses an identity injection policy to insert the basic authentication credentials in the HTTP header of the request and sends it to the Web server.

7. The Web server grants access and sends the requested page to the user.


Secu

rityBrowser

Identity Server LDAP Store

Access Gateway


7

6

When you authenticate to the Identity Server using a non-password-based authentication class, the Identity Server will not prompt for a password. Because no password was entered during authentication, the password in the “Credential Profile” is not filled and cannot be used for Single Sign-On.

Bart Andries wrote a java module that calls the NMAS toolkit and retrievesthe user's password from eDirectory. It can be used then for Injection intothe Authentication Header.Fill Password Java Data Injection Module for NAMhttp://www.novell.com/coolsolutions/appnote/19363.html

Password Injection Java Class

http://www.novell.com/coolsolutions/appnote/19363.html


Secu

rityBrowser

Identity Server

Access Gateway

Web Servers

One Time Password or “OTP”(Vasco Digipass, RSA SecurID, ActivIdentity...)

User Store

RADIUSServer

RADIUS Access-Request

RADIUS Access-Accept / Access-Reject

Verify username and one-time password


AuthenticationClass, Method, Contract


RADIUS Authentication Class

Specify the code (Java class) and properties to be executed to implement a particular authentication type. For a production environment, use ProtectedRadiusClass (RadiusClass, protected by HTTPS).


RADIUS Authentication Class(Properties)

Require password will change the RADIUS login page to also ask the user's password. Some tokens do not have a PIN. When stolen someone can use it (if they know your login-id). Now they also need your password. Plus: this password could be required for webSSO to backend web applications.


RADIUS Authentication Class


Vasco Digipass Integration

Vasco Digipass can use FreeRADIUS and is integrated with iManager.

Tokens and users are in Novell® eDirectory™. There is no need for a separate RADIUS server, nor a separate userstore.

The Digipass becomes an attribute of the user object.

Trust-based Authentication Mechanisms:X.509 and Kerberos


X.509

Is about Public Key Infrastructure (PKI), about certificates and Assymmetric encryptionKeypair: public key and private key (private key is to be kept private)Keys are “bound” by a cypher (an encryption/decryption algorithm)Certificate: public key plus my identity signed by an Authority (CA)Can be used to “sign” a message, to “encrypt” a message or to authenticate a user


X.509 Authentication: How It Works (simplified)

1. The client requests access to a protected application.2. The server requests a certificate from the client

(from the list of supported CA's).3. The client gets a pop up in his browser and selects a certificate to

use (from hist list of certificates which have to be signed by a CA that is trusted by the application).The client sends his certificate and something that he has signed (with his private key).

4. The server validates the signed string, using the user's public key.5. The server checks the validity of the clients certificate with the

Certificate Authority.6. The client and server compute a common secret, called the "master

secret.” All other key data for this connection is derived from this master secret (and the client- and server-generated random values).

1. The client requests access to a protected application.2. The server requests a certificate from the client

(from the list of supported CA's).3. The client gets a pop up in his browser and selects a certificate to

use (from hist list of certificates which have to be signed by a CA that is trusted by the application).The client sends his certificate and something that he has signed (with his private key).

4. The server validates the signed string, using the user's public key.5. The server checks the validity of the clients certificate with the

Certificate Authority.6. The client and server compute a common secret, called the "master

secret.” All other key data for this connection is derived from this master secret (and the client- and server-generated random values).


Browser

LDAP Store

Access Gateway

LDAP(certificate attribute used to lookup the username)

Secu

rity

X.509 Authentication With Novell® Access Manager™

OCSP (Online Certificate Status Protocol)

Trusted CA

Identity Server

(User presents his certificate, which must be from a CA trusted by NAM)

(User presents his certificate, which must be from a CA trusted by NAM)

(See next slide)


X.509 Authentication With Novell® Access Manager™


Kerberos Authentication:How It Works

More info at: http://technet.microsoft.com/en-us/library/bb742516.aspx

UserNetworkServices

1

32

4

65

66

Load Kerbtray from the windows resource kit to explore the Kerberos tickets on the client workstation

http://technet.microsoft.com/en-us/library/bb742516.aspx


Kerberos Authentication:How It Works

More info at: http://technet.microsoft.com/en-us/library/bb742516.aspx

1. Client Logs in to the Kerberos server. 2. Client gets a Ticket Granting Ticket

(on Windows, steps 1 & 2 are done by a domain login).3. Client wants to login to a Kerberized application and sends his TGT

to the KDC, requesting a Service Ticket for that application.4. Client gets his Service Ticket for that application.5. Client presents his Service Ticket to the application.6. Application grants access.

http://technet.microsoft.com/en-us/library/bb742516.aspx


Browser Access Gateway

Secu

rity

Kerberos Authentication With NAM

Identity Server LDAP Store (Does not have to be AD, can be eDir as long as userprincipalname is is on the user object)

For setup see:http://www.novell.com/communities/node/4440/real-life-tips-configuring-kerberos-authentication-access-manager

LDAP lookup on userprincipalname (see next slide)


Browser Access Gateway

Kerberos Authentication With NAM

Identity Server

2. User Accesses Kerberized URL 3. User requests service ticket from KDC

For setup see:http://www.novell.com/communities/node/4440/real-life-tips-configuring-kerberos-authentication-access-manager

LDAP lookup on userprincipalname

LDAP Store (Does not have to be AD, can be eDir as long as userprincipalname is is on the user object)

Internet-based Authentication Mechanisms


Understanding the Trust Model(example Liberty Alliance)

More info at:http://www.novell.com/documentation/novellaccessmanager31/identityserver/data/b6q98sr.html

NovellIdentityServer

AccessGateway

IDPProvides Authentication (SAML, SALM2, Liberty,..)

SP (Consumes SAML, SAML2 and Liberty Authentication)

IDP (Provides Authenticationto ESP (Liberty Only))

ESPConsumes Authentication

Third-PartyIdentityServer

All of these protocols use an Identity Provider (IdP) that provides “Proof of Identity.”The Service Provider (SP) is the website that request authentication before allowing access to its service.In Access Manager, the IdP also contains a SP component which allows it to be chained with another Identity Provider

Novell Access Manager

Third Party

In all of these protocols:• the user is redirected from the SP to the IdP. • the IdP finally sends a SAML assertion to the SP (via the user)

User

Identity Provider

Service Provider 1

2 3


SAML-based Authentications

Liberty and Shibboleth (now) use the standard SAML 2.0 set of protocols and metadata, but WS-* still defines their own protocols and metadata formats on top of SAML 2.0 assertions.

SAML 2.0 Assertions

WS-* protocolsand metadataShibbolethLiberty Shibboleth

SAML 2.0protocols

and metadataShibboleth

Source:”Windows CardSpace”, Jussi MalinenHelsinki University of Technology

SAML 1.1 Assertions

Liberty ID-FFprotocols

and metadata

SAML 1.1protocols

and metadata

Shibboleth 1protocols

and metadata

WS-* protocolsand metadata


OpenID: How It Works

More info at: http://wiki.openid.net/Introduction?mode=print

End User

User Agents

OpenIDServer

Consumer (Service Provider)

Identity Server

1 2 5 10 11

OpenID

3 4

OpenID Redirect

HTML page

HTML form

5

6

7

8

9

10


OpenID: How It Works

1. The user is presented with OpenID login form by the Consumer.

2. User responds with the URL that represents his/her OpenID.

3. Consumer canonicalizes the OpenID URL and uses the canonical version to request (GET) a document from the Identity Server.

4. Identity Server returns the HTML document named by the OpenID URL.

5. The Consumer constructs a URL with mode checkid_setup for the Identity Server and redirects the User Agent. This checkid_setup URL encodes, among other things, a URL to return to in case of success and one to return to in the case of failure or cancellation of the request.

6. The OpenID Server returns a login screen.

7. User sends (POST) a login ID and password to OpenID Server.

8. OpenID Server returns a trust form asking the User if they want to trust Consumer.

9. User POSTs response to OpenID Server.

10.User is redirected to either the success URL or the failure URL.

11.Consumer returns appropriate page to User.


OpenID:Integration With Novell® Access Manager™

For Setup see: http://www.novell.com/communities/node/8951/novell-accessmanager-authentication-class-openid-authentication

1. Download OpenID libraries and copy them in place

2. Download Authentication Class and binaries and copy in place

3. Configure /var/opt/novell/tomcat5/webapps/nidp/WEB-INF/web.xml

4. Create and configure a new authentication class in NAM

5. Create a contract and authentication method to use the authentication class


IdentityProvider

Shibboleth: How It Works

User

ServiceProvider

WAYF

1: Request page 8: Display page

2: Redirect 3: Redirect

4: Userauthenticates

5: Redirect with authentication

6: Request attributes

7: Return attributes


Shibboleth: How It Works

1. The user accesses a protected resource.

2. The resource redirects the user to the WAYF, so that he/she can select his home organisation. Depending on the policy of the federation, the user may be able to record this preference, perhaps in a cookie, for future use.

3. The user is then directed to his home organisation, which sends him to the authentication system for his organisation.

4. The user authenticates himself, by whatever means his organisation deems appropriate for this federation.

5. After successful authentication, a one-time handle or session identifier is generated for this user session, and the user is returned to the resource.

6. The resource uses the handle to request attribute information from the Identity Provider for this user.

7. The organisation allows or denies the attribute information to be made available to this resource using the Attribute Release policy.

8. Based on the attribute information made available, the resource then allows or denies the user access to the resource.


Shibboleth:Integration With Novell® Access Manager™

http://www.novell.com/communities/node/6943/integrating-novells-access-manager-shibboleths-idp-server.../...


CardSpace: How It Works

1. User accesses protected page from web site (=”Relying Party”).2. User selects InfoCard to be used from the Identity Selector (his CardSpace client).3. (Optional) Identity Selector requests more specific details about the security policy of the relying party using WS-MetadataExchange and allows the user to choose from the set of valid InfoCards.4. Identity Selector contacts an accepted IdP (Security Token Server, STS) and requests a token (using WS-MetadataExchange and WS-Trust). 5. User POSTs CardSpace token to Target Page.

User Relying Party

Identity Selector

Browser

InfoCard A

Self-IssuedInfoCard

InfoCard B

Identity Provider A

Identity Provider B

STS

STS

1

5

34

4

2


CardSpace: How It Works

1. User accesses protected page from web site (=”Relying Party”).

2. User selects InfoCard to be used from the Identity Selector (his CardSpace client).

3. (Optional) Identity Selector requests more specific details about the security policy of the relying party using WS-MetadataExchange and allows the user to choose from the set of valid InfoCards.

4. Identity Selector contacts an accepted IdP (Security Token Server, STS) and requests a token (using WS-MetadataExchange and WS-Trust).

5. User POSTs CardSpace token to Target Page


CardSpace: How It Works in Novell® Access Manager™

CardSpace setup with Novell Access Manager is pretty easy and is described at:http://www.novell.com/documentation/novellaccessmanager31/ identityserver/data/bg8df1u.html

1. The NAM Identity Server must be configured for HTTPS.

2. CardSpace requires the high encryption library for JRE. Export laws prevent Access Manager from shipping with it. Download and replace the library files

3. Clients need to be configured with a CardSpace client.

4. Enable the Liberty Personal Profile. The default attribute set created for CardSpace is dependent upon this profile.

5. Click Identity Servers > Edit > Liberty > Web Service Provider. Select the Personal Profile, then click Enable > Apply. Update the Identity Server.

6. (Recommended) Enable Identity Server logging while you are setting up CardSpace. Set the Component File Logger Levels of STS and CardSpace to debug. For more information, see Section 11.3, Configuring Component Logging.

7. (Optional) If you are going to configure an Identity Server to be an identity provider with managed cards, you need a second Identity Server configured as a relying party.

http://www.novell.com/documentation/novellaccessmanager31/


The Bottom line

• Novell® Access Manager™ can be used as an authentication broker.

• It can handle a large variety of authentication mechanisms and provide SSO between them

• Several of these are provided out of the box• Others are provided as a “Cool Solution”

Unpublished Work of Novell, Inc. All Rights Reserved.This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc. Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.

General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for Novell products remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.

Documents

Exploring Advanced Authentication Methods in Novell Access Manager