Presentation is loading. Please wait.

Presentation is loading. Please wait.

Development and Implementation of Multifactor Authentication Motonori Nakamura at National Institute of Informatics and Takuya Matsuhira at Kanazawa University,

Similar presentations


Presentation on theme: "Development and Implementation of Multifactor Authentication Motonori Nakamura at National Institute of Informatics and Takuya Matsuhira at Kanazawa University,"— Presentation transcript:

1 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

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

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

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

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.

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)

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. (It’s 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. (It’s described in the SAML assertion as Authentication Context Class.)

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.

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 It’s 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

10 2nd TEIN IAM Workshop 10  tiQr has been developed by SURFnet.  It’s implemented as a smartphone apps (available iOS and Android).  It’s 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

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 don’t 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.

12 2nd TEIN IAM Workshop 12  Improvement of authentication mechanism of Shibboleth  Switch authentication method according to user’s 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 can’t 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”.

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.

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.

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.

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

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

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

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

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

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.


Download ppt "Development and Implementation of Multifactor Authentication Motonori Nakamura at National Institute of Informatics and Takuya Matsuhira at Kanazawa University,"

Similar presentations


Ads by Google