Exploring Advanced Authentication Methods in Novell Access Manager

Exploring Advanced Authentication Methods in
Novell® Access Manager™
Chris Van Den Abbeele
Solution Manager Identity Security Risk Management
Chris.VanDenAbbeele@AtosOrigin.com
Atos 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 protocols
SAML and co.
• Authentication and Authorization outsourced:
Information Cards / Cardspace

Local Authentication
Novell® Access Manager™
Theory of Operations

Browser
Identity Server
Access Gateway
Web Servers
LDAP
(username/password)
42
4
1
5
3
7
6
Security
LDAP Store
(Username / password authentication)

Security
Browser
Identity Server
LDAP Store
Access Gateway
Web Servers
LDAP
(username/password)
7

Security
Browser
Identity Server
LDAP Store
Access Gateway
Web Servers
LDAP
(username/password)
1

Identity Server
Security
Browser
LDAP Store
Access Gateway
Web Servers
LDAP
(username/password)
2
2

Security
Browser
Identity Server
LDAP Store
Access Gateway
Web Servers
LDAP
(username/password)3

Security
Browser
Identity Server
LDAP Store
Access Gateway
Web Servers
LDAP
(username/password)
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

Security
Browser
Identity Server
LDAP Store
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

Browser
Identity Server
LDAP Store
Access Gateway
LDAP
(username/password)
7
6
Security

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.

Security
Browser
Identity Server
LDAP Store
Access Gateway
LDAP
(username/password)
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 retrieves
the user's password from eDirectory. It can be used then for Injection into
the Authentication Header.
Fill Password Java Data Injection Module for NAM
http://www.novell.com/coolsolutions/appnote/19363.html
Password Injection Java Class

Security
Browser
Identity Server
Access Gateway
Web Servers
One Time Password or “OTP”
(Vasco Digipass, RSA SecurID, ActivIdentity...)
User
Store
RADIUS
Server
RADIUS Access-Request
RADIUS
Access-Accept /
Access-Reject
Verify
username
and one-time
password

Authentication
Class, 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).

(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.

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 encryption
Keypair: 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)
Security
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
User
Network
Services
1
32
4
6
5
66
Load Kerbtray from the windows
resource kit to explore the
Kerberos tickets on the client
workstation

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.

Browser Access Gateway
Security
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/novellaccessm
anager31/identityserver/data/b6q98sr.html
Novell
Identity
Server
Access
Gateway
IDP
Provides Authentication
(SAML, SALM2, Liberty,..)
SP (Consumes SAML,
SAML2 and
Liberty Authentication)
IDP (Provides Authentication
to ESP (Liberty Only))
ESP
Consumes Authentication
Third-Party
Identity
Server
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 Provider1
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-* protocols
and metadata
ShibbolethLiberty Shibboleth
SAML 2.0
protocols
and metadata
Shibboleth
Source:
”Windows CardSpace”, Jussi Malinen
Helsinki University of Technology
SAML 1.1 Assertions
Liberty ID-FF
protocols
and metadata
SAML 1.1
protocols
and metadata
Shibboleth 1
protocols
and metadata
WS-* protocols
and metadata

OpenID: How It Works
More info at: http://wiki.openid.net/Introduction?mode=print
End User
User
Agents
OpenID
Server
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

Identity
Provider
Shibboleth: How It Works
User
Service
Provider
WAYF
1: Request page 8: Display page
2: Redirect 3: Redirect
4: User
authenticates
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-Issued
InfoCard
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.

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 Disclaimer
This 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.

Exploring Advanced Authentication Methods in Novell Access Manager

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Exploring Advanced Authentication Methods in Novell Access Manager

Semelhante a Exploring Advanced Authentication Methods in Novell Access Manager (20)

Mais de Novell

Mais de Novell (20)

Exploring Advanced Authentication Methods in Novell Access Manager