Development and Implementation of Multifactor Authentication Motonori Nakamura at National Institute...
If you can't read please download the document
Development and Implementation of Multifactor Authentication Motonori Nakamura at National Institute of Informatics and Takuya Matsuhira at Kanazawa University,
Development and Implementation of Multifactor Authentication
Motonori Nakamura at National Institute of Informatics and Takuya
Matsuhira at Kanazawa University, Japan 2nd TEIN IAM Workshop1 2nd
TEIN IAM Workshop in Kuala Lumpur
Slide 2
2nd TEIN IAM Workshop 2 Present situation of user
authentication in Kanazawa University Standard authentication
mechanism in Shibboleth An Authentication method selection
mechanism GUARD plug-in A sample scenario using the mechanism
Conclusion & Future work
Slide 3
2nd TEIN IAM Workshop 3 Kanazawa University Single Sign On
KU-SSO Authentication infrastructure in Kanazawa University KU-SSO
is based on Shibboleth. Identity Provider (IdP) as an
authentication server. Various Information Systems in Kanazawa
University are Service Providers (SPs). Single-Sign On
(Authentication) and attribute sharing among SPs (Authorization)
have been realized. Full-scale operation has been started since
March 2010. Currently, approximately 30 information systems have
been shibbolized. Tokyo Kanazawa Kyoto Fukuoka
Slide 4
2nd TEIN IAM Workshop 4 Access within campus is permitted by
all SPs. But access from outside of campus is not permitted by many
SPs. (blocked by firewall) e.g. Salary specification providing
system, Financial system, etc. VPN is required to access such SPs
from outside of campus To protect weak username/password
authentication
Slide 5
2nd TEIN IAM Workshop 5 Every VPN mechanisms are not supported
by all operating systems. Usage of VPN is not easy for the general
users. But it is important to support access from outside of
campus. Access from home During business trip Mobile access during
commuting Easier way than VPN is needed for users to access all SPs
from outside of campus. Easier way than VPN is needed for users to
access all SPs from outside of campus.
Slide 6
2nd TEIN IAM Workshop 6 Factors for authentication are
generally classified into three types. Knowledge factor: "something
only the user knows" e.g., password, PIN, pattern Risks (such as
leaks and speculation) are high only knowledge factor. Possession
factor: "something only the user has" e.g., ATM card, IC card,
smartphone, OTP calculator Inherence factor: "something only the
user is" e.g., biometric characteristic, such as a fingerprint
Definition of multi-factor authentication Require more than two
kind of factors described above. e.g. IC Card (Possession factor)
and a PIN (Knowledge factor)
Slide 7
2nd TEIN IAM Workshop 7 SP 1. A user accesses to the SP. 2. The
SP specifies the authentication method and notifies to the IdP.
(Its described in the SAML assertion as Authentication Context
Class.) IdP 3. The IdP selects the authentication method which the
SP specifies from defined authentication methods and presents it to
the user. 1 2 User 3 4 5 4. The user does authentication presented
from the IdP. AuthN method A (Username/Password) AuthN method A
(Username/Password) AuthN method B AuthN method N 5. After
successful authentication, the IdP informs authentication method
the user did to the SP. (Its described in the SAML assertion as
Authentication Context Class.)
Slide 8
2nd TEIN IAM Workshop 8 AuthenticationEngine selects the AuthN
method specified by Authentication Context Class. Selected AuthN
method performs the authentication process. Username/Password authN
is selected by default if not specified from SP. Shibboleth IdP
AuthN method A (Username/Password) AuthN method A
(Username/Password) AuthenticationEngine AuthN method B SP requests
authentication to IdP. When SP requests Username/Password
authentication, Authentication Context Class is described
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
AuthN method N IdP selects AuthN method (LoginHandler) specified by
Authentication Context Class. IdP selects AuthN method
(LoginHandler) specified by Authentication Context Class.
Slide 9
2nd TEIN IAM Workshop 9 By default, Shibboleth doesn't have
multi-factor authentication method. There are several ways to apply
authentication methods in Shibboleth. 1.Use Remote User Login
Handler In case an implementation puts the ID to REMOTE_USER
environment variable. e.g., How to use Apache basic authentication
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser
2.Use External Authentication Login Handler In case an
implementation passes the ID in java code. tiQr authentication
(described later) is implemented in this way. 3.Implement Login
Handler by yourself Its available for all implementation, but too
complicated. e.g., How to use One-time password authentication
https://wiki.shibboleth.net/confluence/display/SHIB2/Multi+Factor+Login+Handler
Slide 10
2nd TEIN IAM Workshop 10 tiQr has been developed by SURFnet.
Its implemented as a smartphone apps (available iOS and Android).
Its multi-factor authentication. [Smartphone(Possession factor) and
PIN(Knowledge factor)] It reduces login operation of users using
the QR code. Authentication procedure of tiQr 1. QR code is
displayed during authentication. 2. Scan the QR code with the
camera function of the smartphone. 3. Enter the 4-digit pin code
(number). NII provides a method in order to use tiQr in Shibboleth.
https://meatwiki.nii.ac.jp/confluence/display/tiqr/Home
Slide 11
2nd TEIN IAM Workshop 11 Multi-factor authentication in
Shibboleth is possible. multi-factor authentication (in general) It
takes more time than Username/Password authentication. If a user
dont have a specified possession (Smartphone, IC card, etc.),
he/she can't be authenticated. Username/Password authentication
method cannot be replaced with multi-factor authentication method
simply and completely. Multi-factor authentication is not required
always. Multi-factor authentication is required only under specific
situations.
Slide 12
2nd TEIN IAM Workshop 12 Improvement of authentication
mechanism of Shibboleth Switch authentication method according to
users IP address. Username/Password (when accessed within the
campus) Multi-factor (when accessed from outside of the campus) We
want to realize risk-based authentication. One of multiple
authentication methods can be selected Users w/o smartphone cant
use tiQr authentication. To spread multi-factor authentication in a
university, it is important to provide alternative methods for
users who can't use tiQr. e.g., tiQr authentication or IC card
authentication Stronger authentication is required for SP which
deals with very important information. e.g., tiQr authentication
and IC card authentication We have developed Authentication method
selection mechanism.
Slide 13
2nd TEIN IAM Workshop 13 Gakunin mUlti Authentication mechanism
with Risk-based Decision plug-in Setting of IdP Call one jar file
in order to change the processing of AuthenticationEngine. Define
whitelist of IP addresses. IP addresses in the whitelist are
treated as inside. e.g., IP address used in the campus network
(X.X.X.X/16) Define the authentication method at each level. (You
can defined any number of levels). e.g., Level1 Username/Password
(access from both inside and outside) Level2 Username/Password
(access from inside) One-time password or tiQr (access from
outside) Level3 One-time password and tiQr (both inside and
outside) Setting of SP Just send level information instead of
Authentication Method.
Slide 14
2nd TEIN IAM Workshop 14 MultiLevelAuthenticationEngine selects
authentication method(s) corresponding to the level specified by an
SP with Authentication Context Class. Username/Password authN is
selected by default if level is not specified by an SP. Shibboleth
IdP AuthenticationEngine SP requests authentication level to IdP.
When SP requests level1, Authentication Context Class is described
urn:mace:gakunin.jp:idprivacy:ac:classes:Level1
MultiLevelAuthenticationEngine AuthN method A (Username/Password)
AuthN method B (One-time password) AuthN method B (One-time
password) AuthN method C (tiQr) AuthN method C (tiQr) AuthN
methods(LoginHandlers) corresponding to the level specified by
Authentication Context Class is selected.
Slide 15
2nd TEIN IAM Workshop 15 Username/Password authentication is
offered for an SP which satisfied with simple authentication
(Level1). For an SP which requires higher authentication level, IdP
requires multi-factor authentication (Level2 or above) in
accordance with IP addresses on the whitelist. An authentication
level at IdP satisfies the same and lower level requests from SP.
After a user authenticated for access to an SP, when he/she
accesses another SP; SSO (no authentication needed) if the SP
requires the same level as or lower level than the previous SPs.
IdP requires authentication method for a level specified by the SP
if the SP requires upper level than the previous SPs.
Slide 16
2nd TEIN IAM Workshop 16 Three levels are defined at IdP Level1
Username/Password (access from both inside and outside) Level2
Username/Password (access from inside) tiQr or One-time Password
(access from outside) Level3 tiQr and One-time Password (access
from both inside and outside) There are three SPs in Kanazawa Univ.
Portal site requests Level1. Campus terms site requests Level2.
Financial system requests Level3. IdP SP1(Portal site) SP2(Campus
terms site) SP3(Financial system) Level1 Level2 Level3 AuthN method
A (Username/Passsword) AuthN method A (Username/Passsword) AuthN
method B (One-time Password) AuthN method B (One-time Password)
AuthN method C (tiQr) AuthN method C (tiQr) Access within campus
Access from outside of campus IdP checks IP address of user
Whitelist (inside) IP address of Kanazawa University (IP
XX.XX.0.0/16) GUARD Plug-in KU-SSO
Slide 17
2nd TEIN IAM Workshop 17 Level1 is defined as Username/Password
(access from both inside and outside). Users access to the portal
site. Service starts. Username/Password is required. Login success
From both inside and outside IP
Slide 18
2nd TEIN IAM Workshop 18 Level2 is defined as Username/Password
(for inside), and tiQr or One-time Password (for outside). From
inside IP From outside IP Users access to the campus terms site.
tiQr is selected. One-time Password is selected. Username/Password
is required. Login success authentication method selection. Login
success Login success Service starts
Slide 19
2nd TEIN IAM Workshop 19 Level 3 is defined as One-time
Password and tiQr (access from both inside and outside). Users
access to the Financial System. One-time Password is required. tiQr
is required. Service starts Success Login Success From both inside
and outside campus
Slide 20
2nd TEIN IAM Workshop 20 We have developed GUARD plug-in system
for Shibboleth IdP to provide authentication method selection
mechanism depending on request from an SP. Various policies can be
defined. Fore example: Level 1: Username/Password authentication
Level 2: Username/Password for inside campus, and multi-factor
authentication for outside of campus Level3: dual multi-factor
authentication Similar module Multi Context Broker is in
development at Internet2
https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-
Context+Broker
Slide 21
2nd TEIN IAM Workshop 21 Now we are applying the GUARD plug-in
in KU-SSO environment for trial and evaluation. After the trial, we
will release the GUARD plug-in as an open source. (around end of
March 2015) Federation wide standard on authentication level should
be defined.