OpenAM – HOTP
HMAC One-Time Password
4
5
OpenAM prompts for AD UserName/
Password credentials
User vetted and managed
locally in the Active Directory
LDAP
Secure Token One Time
Password
browser
2
UAG delegates authentication to ADFS
3
ADFS redirects to the OpenAM
Authentication Server that is also protected
by the UAG. ADFS defines OpenAM as an
Account Provider.
9
SAML Assertion (token) received by ADFS
10
SAML Token transformed into Claim Token
and passed to SharePoint in the Request
Header
SAML Assertion passed to OAG in the
Request Header
If the credentials are invalid access is denied
OpenAM sends the One-Time Password (OTP)
to cell phone/email account via SMTP
1
7
OpenAM prompts for OTP
8
OpenAM validates OTP
access
9
SharePoint 2010 Portal resource requested
that is protected by the UAG ADFS Trunk
OpenAM validates credentials
access
6
1
10
UAG SP1
Define ADFS Authenticated
Trunk with ADFS Authenticated
Applications
If the OTP is invalid access is denied
6
OpenAM returns the SAML Assertion
7
or
3
10
9
9
4
2 .0 a s
FS nAM er
AD Ope rovid
e
P
2
nAM
Ope cation
ti
n
e
Auth erver
5 S
8
If the user has a hard token then
the user enter the RADIUS
password at the same time they
enter their credentials for the AD.
Steps 6-8 are skipped.
fin nt
De cou
Ac
3
10
10
5
RADIUS
Server
OAG Portal
SAML Assertion
5
SharePoint Portal
Claims Based
SAML
Active Directory
Two-Factor Authentication using a One-Time Password
OTP Delivered or OTP Generated by Hard Token
The above diagram depicts the potential use for OpenAM in the role of authentication server.
OpenAM can work with the current SafeWord Tokens validating against the RADIUS server but
it also has a one time password (OTP) authentication module. The authentication module is
based on the HMAC-based One Time Password (HOTP) algorithm
(http://www.ietf.org/rfc/rfc2104.txt http://www.ietf.org/rfc/rfc4226.txt). HMAC stands for
Keyed-Hash Message Authentication Code and is a FIPS standard
(http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf).
The UAG provides the boundary security into our network. ADFS provides the authentication
flow from the UAG and transforms SAML assertions into the Claim Token used by SharePoint
in claims based authentication. OpenAM provides the authentication process with the HOTP and
RADIUS. OpenAM also provides the SAML 2.0 support where ADFS provides SAML 1.1
support.
OpenAM – HOTP
HMAC One-Time Password
The HOTP authentication module works in tandem with one or more other authentication
modules (such as LDAP or Active Directory) as part of an authentication chain. Authentication
to at least one of the other modules in the chain must be successful before attempting HOTP
authentication. HOTP requires the user profile that is obtained by a successful authentication to
one of the prior authentication module(s) in the authentication chain.
Configuring HOTP as part of an authentication chain constitutes two-factor authentication where
the authentication process comprises something the user has (a cell phone or email account) as
well as something the user knows (the one-time password in addition to their username/password
authentication to the LDAP or Active Directory).
OpenAM – HOTP
HMAC One-Time Password
If the authentication to the LDAP is successful the user is presented with the form to request the
OTP Code.
The user receives the One Time Password (OTP) in an email or text message on their cell phone.
The email message has a subject of ‘OpenAM One Time Password’ and the message looks like:
If received on the user’s cell phone the text message would be similar to the following:
Urgent MSG
From: opensso@sun.com
(OpenAM One Time Password) Your OpenAm On Time Password: 01994051
OpenAM – HOTP
HMAC One-Time Password
To change who the message is from and/or the message you need to change the
amAuthHOTP.properties files.
Change to:
messageFrom=CLIX.Helpdesk@doj.ca.gov
messageSubject=CLIX One Time Password
messageContent=Your CLIX One Time Password :
Once the user has received the OTP they would enter it in form and click the ‘Submit’ button to
continue the authentication process.
To communicate the OTP securely between parties, a hashed message authentication code
(HMAC) is used to encode the data. When a onetime password is requested, the HOTP
authentication module stores the OTP in memory, appends an authentication tag to it that is
computed as a function of the one-time password and the HMAC, and sends it to the user. When
the user returns the one time password, the HOTP authentication module will compare the one
received with the one it stores in memory and authentication succeeds only if the values match.
Note: OpenAM uses a secure hash algorithm (SHA-1) to generate the HMAC code. SHA-1 is a
cryptographic hash algorithm published by the United States Government. It produces a 160-bit
hash value from an arbitrary length string.
OpenAM – HOTP
HMAC One-Time Password
In order for HOTP authentication to work the user must be set up in the Active Directory
(LDAP) with a valid email address and/or telephone entry. The telephone entry must be a cell
phone number and the carrier has to be appended to the number. For Instance a Verizon
Wireless number would be entered as:
9165551212@vtext.com
How long the OTP is valid for is a configurable option in OpenAM. The default is five minutes
but can be set to as little as one minute. The length of the OTP can be set to either six or eight
digits.
OpenAM – HOTP
HMAC One-Time Password
Configuring OpenAM in conjunction with the UAG and ADFS implements a federated model of
two factor authentication for the user base we manage. It may even provide the necessary pieces
to federate with other federations but further investigation into the details of the governance
model for each federation is required.
The approach would be to first implement the two factor HOTP model for the SharePoint 2010
Portal. Accessing the SharePoint Portal would encompass the following steps:









An unauthenticated user attempts to access the SharePoint Portal via the url that is
hosted/protected by the UAG.
The UAG delegates the authentication process to ADFS. ADFS would be configured to
use OpenAM as the account provider meaning that ADFS would send a browser redirect
to the OpenAM Authentication Server via a proxy URL that is hosted/protected by the
UAG. Note: We would most likely need to create a custom authentication module for
the UAG protecting OpenAM that inspects the request header looking for evidence that
the request came from the ADFS redirect.
OpenAM would then send to the browser the initial request for the username/password
credentials used by the Active Directory.
If the credential were valid OpenAM would send via SMTP a one-time password (OTP)
to the user's cell phone and/or email account.
OpenAM sends to the browser a form requesting the OTP.
The user would use the OTP received to submit back to OpenAM.
If the OTP is valid OpenAM sends a SAML Assertion back to ADFS.
ADFS transforms the SAML Assertion into a SAML Claim Token that SharePoint uses.
With the user now authenticated ADFS redirects (via the UAG) back to the original url
requested with the SAML Claim Token.
OpenAM – HOTP
HMAC One-Time Password
4
5
OpenAM prompts for AD UserName/
Password credentials
User vetted and managed
locally in the Active Directory
LDAP
browser
2
UAG delegates authentication to ADFS
3
ADFS redirects to the OpenAM
Authentication Server that is also protected
by the UAG. ADFS defines OpenAM as an
Account Provider.
9
SAML Assertion (token) received by ADFS
10
SAML Token transformed into Claim Token
and passed to SharePoint in the Request
Header
If the credentials are invalid access is denied
OpenAM sends the One-Time Password (OTP)
to cell phone/email account via SMTP
1
7
OpenAM prompts for OTP
8
OpenAM validates OTP
access
9
SharePoint 2010 Portal resource requested
that is protected by the UAG ADFS Trunk
OpenAM validates credentials
access
6
1
10
UAG SP1
Define ADFS Authenticated
Trunk with ADFS Authenticated
Applications
If the OTP is invalid access is denied
6
OpenAM returns the SAML Assertion
7
3
9
9
4
2 .0 a s
FS enAMider
D
v
p
A
2
M
penA tion
8 O
a
c
i
t
n
e
Auth erver
5 S
o
e O Pr
fin nt
De cou
c
A
3
10
5
SharePoint Portal
Claims Based
SAML
Active Directory
SharePoint 2010 Portal Access with Two-Factor Authentication using a One-Time Password
OpenAM – HOTP
HMAC One-Time Password
Once the SharePoint Portal use case has been completed successfully the next step would be to
integrate the OAG Portal with the hard token OTP (Secure Token) and the HOTP such that we
can utilizes the existing hard tokens and lower future costs using the HOTP delivery module for
new users.
4
5
OpenAM prompts for AD UserName/
Password credentials
User vetted and managed
locally in the Active Directory
LDAP
Secure Token One Time
Password
browser
2
UAG delegates authentication to ADFS
3
ADFS redirects to the OpenAM
Authentication Server that is also protected
by the UAG. ADFS defines OpenAM as an
Account Provider.
9
SAML Assertion (token) received by ADFS
If the credentials are invalid access is denied
OpenAM sends the One-Time Password (OTP)
to cell phone/email account via SMTP
1
7
OpenAM prompts for OTP
8
OpenAM validates OTP
access
9
SharePoint 2010 Portal resource requested
that is protected by the UAG ADFS Trunk
OpenAM validates credentials
access
6
1
10
UAG SP1
If the OTP is invalid access is denied
6
OpenAM returns the SAML Assertion
10
Define ADFS Authenticated
Trunk with ADFS Authenticated
Applications
7
3
SAML Assertion passed to OAG in the
Request Header
9
9
4
2
M
penA tion
8 O
ntica
e
h
t
Au
rver
5 Se
If the user has a hard token then
the user enter the RADIUS
password at the same time they
enter their credentials for the AD.
Steps 6-8 are skipped.
2 .0 a s
FS enAMider
D
v
p
A
e O Pr
fin nt
De cou
Ac
3
o
10
5
RADIUS
Server
OAG Portal
SAML Assertion
5
Active Directory
Two-Factor Authentication using a One-Time Password
OTP Delivered or OTP Generated by Hard Token
At this stage users should be cross authenticated to both the SharePoint Portal and the OAG
Portal where applicable.
OpenAM – HOTP
HMAC One-Time Password
Some definitions from Wikipedia:
HMAC
From Wikipedia
http://en.wikipedia.org/wiki/HMAC
In cryptography, HMAC (Hash-based Message Authentication Code), is a specific construction
for calculating a message authentication code (MAC) involving a cryptographic hash function in
combination with a secret key. As with any MAC, it may be used to simultaneously verify both
the data integrity and the authenticity of a message. Any cryptographic hash function, such as
MD5 or SHA-1, may be used in the calculation of an HMAC; the resulting MAC algorithm is
termed HMAC-MD5 or HMAC-SHA1 accordingly. The cryptographic strength of the HMAC
depends upon the cryptographic strength of the underlying hash function, the size of its hash
output length in bits and on the size and quality of the cryptographic key.
HOTP
From Wikipedia
http://en.wikipedia.org/wiki/HOTP
HOTP is an HMAC-based One Time Password algorithm. It is a cornerstone of Initiative For
Open Authentication (OATH).
HOTP was published as an Information IETF RFC 4226 in December 2005, documenting the
algorithm along with a Java implementation. Since then, the algorithms was adopted by many
companies worldwide[citation needed] and became the world's leading standard[citation needed] for eventbased OTP authentication. The HOTP algorithm is a freely available open standard.
OTP
From Wikipedia
http://en.wikipedia.org/wiki/One-time_password
A one-time password (OTP) is a password that is valid for only one login session or
transaction. OTPs avoid a number of shortcomings that are associated with traditional (static)
passwords. The most important shortcoming that is addressed by OTPs is that, in contrast to
static passwords, they are not vulnerable to replay attacks. This means that, if a potential intruder
manages to record an OTP that was already used to log into a service or to conduct a transaction,
he or she will not be able to abuse it since it will be no longer valid.
OpenAM – HOTP
HMAC One-Time Password
OTP generation algorithms typically make use of randomness. This is necessary because
otherwise it would be easy to predict future OTPs from observing previous ones. Concrete OTP
algorithms vary greatly in their details. Various approaches for the generation of OTPs are listed
below.



Based on time-synchronization between the authentication server and the client
providing the password (OTPs are valid only for a short period of time)
Using a mathematical algorithm to generate a new password based on the previous
password (OTPs are, effectively a chain and must be used in a predefined order).
Using a mathematical algorithm where the new password is based on a challenge (e.g.,
a random number chosen by the authentication server or transaction details) and/or a
counter.
There are also different ways to make the user aware of the next OTP to use. Some systems use
special electronic tokens that the user carries and that generate OTPs and show them using a
small display. Other systems consist of software that runs on the user's mobile phone. Yet other
systems generate OTPs on the server-side and send them to the user using an out-of-band
channel such as SMS messaging. Finally, in some systems, OTPs are printed on paper that the
user is required to carry with them.
Note: As far as where the HOTP fits within the NIST Level definitions as indentified in SP80063 it not easy to say. In reading through the levels there is not an exact match but I’m of the
opinion that the use of the HOTP in conjunction with the Active Directory authentication fits into
the NIST Level 3 Authentication Assurance arena. The parts and pieces are there just in a
different configuration then what is defined. However, this is simply my opinion.