Changes between Version 13 and Version 14 of mfa


Ignore:
Timestamp:
10/24/16 13:32:26 (8 years ago)
Author:
dabantz@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • mfa

    v13 v14  
    44Two-factor authentication requires users to provide a "second factor" in addition to the correct password to authenticate and gain access to resources.  If your password is "something you know", the second factor can be described as "something you have" such as your working telephone or smartphone.  [In principle the second - or third - factor could be "something you are" such as fingerprint or voiceprint recognition.] 
    55 
    6 The UA Identity Provider has been extended to allow use of two-factor authentication using Duo Security.  When two-factor authentication is invoked (as described below) you will first provide your identifier and UA Password just as you usually do for most applications.  If and only if your password is verified a second screen will ask for the second factor.  That second factor may be one of the following: 
    7  * replying "Approve" in a request for access sent to a smartphone app on your registered phone 
    8  * entering a code sent via text to your registered cell phone 
    9  * entering a code your hear in a voice call to your registered phone 
    10  * taping an installed UBIkey token (currently requires using Chrome browser). 
     6The UA Identity Provider has been extended to allow use of two-factor authentication using Duo Security.  When two-factor authentication is invoked (as described below) you will first provide your identifier and UA Password just as you usually do for most applications.  Some services will soon require use of 2 factor authentication. You can opt in to use of 2 factor authentication by sending email to ua-iam-dept@alaska.edu. 
    117 
    12 [[Image(Duo_login.png)]] 
     8What does the user experience look like? 
    139 
    14 Login page request after password verified, showing options available for 2nd factor [[br]] 
    15 [[br]]Any of those methods demonstrate you "have" the registered device or phone number.  The smartphone app is generally regarded as the most convenient, as you do not have to type a code.  Image of the Duo smartphone app showing request for login is below: 
     10Once your identity is flagged for 2 factor authentication, your first access of one of the relying services triggers a login screen requesting your UA Username and UA Password (figure 1A). Your UA Username and UA Password are verified against UA’s directory service (never exposed to the service itself). Once verified, you will be prompted to provide a second factor – something you have (figure 1B). Assuming you use the recommended option “Send Me a Push”, you will need to accept the request pushed to the Duo app on your smart phone (figure 1C).  
    1611 
    17 [[Image(Duo_app_login_request.png)]] [[br]] 
     12[[Image(2FA_user_experience.png)]] 
    1813 
    1914A one-time registration process records a user's phone number and preferred means of providing the second factor.  That is, the initial registration associates a specific phone number and mode of communication with your UA Username or ID #.  A single user may have multiple registered second factors; for example, you might have a smartphone that uses the Duo Security app and a land line on which you can receive a voice call providing a one-time code.   
    2015 
    21 == Invoking two-factor authentication == 
    22 At least two means of invoking two-factor authentication are envisioned: 
     16When you access other relying services during the day from the same browser on the same computer, you will not be prompted to authenticate again. 
    2317 
    24 (1) A service can request two-factor authentication when relying on the Identity Provider to authenticate users.  It does so by explicitly requesting the two-factor "authnContext" in its request.  An important caveat is that the Identity Provider is not in general guaranteed to honor that request.  The Identity Provider may not be capable of a particular method and default or fall back to some other method.  The Identity Provider will include a precise indication of the method it did use to authenticate the user, but it is up the relying service to verify that the method used provided what that service considers an acceptable method and to respond accordingly.  That is, the SP might deny access altogether if the the authentication method was not that requested, or it may allow access to some portion of the service. 
     18If you access any of the relying services in a different browser (use a different web browser on the same computer, or use a different computer) you will need to re-authenticate because the new browser does not have the information that you have authenticated. 
    2519 
    26 The authentication context to request Duo two-factor authentication is: 
    27 https://iam.alaska.edu/trac/wiki/mfa 
     20Which other services participate in SSO and will not require additional authentication? 
     21A list of about 50 services relying on SSO via the UA Identity Provider is at: 
     22https://iam.alaska.edu/trac/wiki/IamUaArp#Services 
     23Other research and scholarship services are potentially available as well if they participate in the !InCommon federation. A list of 250+ “partners” that provide information services to higher education is at https://www.incommon.org/participants/ . 
    2824 
    29 (2) An individual user can require two-factor authentication for their identity.  A user desiring higher assurance that others do not impersonate them can indicate that anyone using their UA Username or ID # will be required by the Identity Provider to use 2-factor authentication.  If you invoke this option for your UA identity, anyone attempting to authenticate as you will need not only your UA Username or ID # and your UA Password but access to your registered phone in order to provide the second factor, thus making such impersonation more difficult and less likely. 
     25== Why is UA deploying 2 factor authentication? What is the benefit? == 
     26Second factor authentication mechanisms provide greater assurance of correctly identifying users and preventing abuses when someone’s username and password are compromised. Federal guidelines for agencies require 2 factor authentication in cases where a compromise could entail “moderate” inconvenience or distress or damage or financial loss or liability or if there is “any” risk of unauthorized release of sensitive information. Like most institutions, UA increasingly relies on web-based applications, which are primary targets of exploits. Many attacks (a Verizon summary of breaches states 95%) involve harvesting credentials from end user devices, then using them to log into web services. For example, CU Boulder potentially experienced a compromised emergency system during a police incident resulting in several false active-shooter reports. Boston University implemented 2 factor authentication after compromised passwords enabled employee payroll deposits to be diverted.  
    3027 
    31 Your identity requires Duo two-factor authentication if, and only if, you are designated in the UA Enterprise LDAP ("eDir") to be in the following group: 
    32         cn=security:IdP:require2factor,ou=group,dc=alaska,dc=edu 
    33 Currently (in the initial roll-out of two-factor authentication at UA) you can request this group membership and use of !DuoSecurity two-factor authentication by request to IAM (email iam@alaska.edu). 
     28== Are other Universities using 2 factor authentication? Are they using Duo Security? == 
     29Yes and yes. Many institutions have adopted 2 factor authentication and require its use to access key institutional services. Some require use by all employees and at least one (Virginia Tech) requires use by both employees and students.  Over 100 Universities have agreements with Duo; several of them have very large implementation with many thousands of users. 
     30  
     31== Which identities use Duo 2 factor authentication? == 
     32Participation at UA is being gradually deployed. Identities that have a group membership indicating use of 2 factor authentication will automatically be presented with the challenge for 2nd factor to authenticate. For now, users contact IAM and request membership in 2 factor authentication group. A service owner may require users to be enrolled in 2FA to access that service. 
    3433 
    35 (3) More complex logic is possible.  See the section below on "per SP" configuration of the MCB. 
     34What services or which identities require Duo 2 factor authentication?  
     35DocuSign (electronic signatures), Amazon Web Services administrator access, and RAVE emergency communications are the first services at UA being configured to require 2 factor authentication. Other services may require 2 factor authentication if and when service owners determine it is appropriate. Users who have not enabled 2 factor authentication will not be able to access these services until they opt in to 2 factor authentication for their UA identity. 
    3636 
    37 == Enrolling and configuring your phone or other second factor == 
    38 If your authentication invokes two factor authentication (via either of the methods above - because a service requires it or because you are in the security group using two factor) and you have not previously used Duo Security with UA, you will be presented with a page to automatically enroll and designate your phone number to be used for second factor.   
     37== What if I do not have or decline to use my smartphone as 2nd factor? == 
     38You may enroll other types of devices either as backup or alternatives to a smartphone: 
     39• a mobile phone that can accept SMS text messages;  
     40• any telephone number to receive a call from Duo that will prompt for a response;  
     41• a small USB token from YubiKey (with the Chrome browser only); or  
     42• receive a series of one time codes (via SMS text) you can copy and enter as needed.  
     43The experience of many thousands of users suggests the smartphone app is almost always the most convenient and least obtrusive mechanism, but you are encouraged to enroll other devices in case your smartphone is unavailable. 
    3944 
    40 == Implementation == 
     45== How do I enroll devices to be used as 2nd factor? == 
     46You will be automatically prompted to enroll devices the first time you access a relying service after opting in to 2 factor authentication. Detailed description of the process is in the following draft documentation: 
     47https://docs.google.com/document/d/1-TtMfYeUzEbac_U_CECFZY0nVv1dibT-XRLmq4Ew9pQ 
    4148 
    42 As of 2014-06-25 Duo Security two-factor authentication is integrated with the production UA Identity Provider. 
     49=== Enrolling and configuring your phone or other second factor === 
     50If your authentication invokes two factor authentication (because a service requires it or because you are in the security group using two factor) and you have not previously used Duo Security with UA, you will be presented with a page to automatically enroll and designate your phone number to be used for second factor.   
    4351 
    44 == Users can enroll and configure devices in the Duo Self Service Portal == 
     52=== Users can enroll and configure devices in the Duo Self Service Portal === 
    4553 
    4654Users may manage or add managed devices for second factor authentication in Duo's Self Service Portal. 
    … …  
    5361[[Image(Enroll_device.png)]] 
    5462 
    55 More detailed user documentation is at http://guide.duosecurity.com/manage-devices . 
    56  
    57 == Configuring the MCB to require 2FA based on the SP == 
    58 Scott Koranda via shibboleth.net  
    59 2015-04-17 
    60  
    61 to Shibboleth  
    62 Hello, 
    63  
    64 The MCB can be configured to use an attribute to determine which 
    65 authentication contexts are allowed for a user, ie. 
    66  
    67 <idms attributeResolverID="allowedAuthContexts" /> 
    68  
    69 Further the attribute can be of type "Script" and have a dependency on 
    70 other attributes such as the value of isMemberOf from an LDAP query on 
    71 the principal. 
    72  
    73 Still further, the script can ascertain the SP by making a call to 
    74  
    75 peerEntityId = String(requestContext.getPeerEntityId()); 
    76  
    77 Is it not the case then the logic in the scripted 
    78 "allowedAuthContexts" attribute can be such that it can make a 
    79 decision on which authentication contexts be allowed for a user by 
    80 combining the user's LDAP record and the entityID of the SP which the 
    81 user is attempting to access? 
    82  
    83 The mechanism described above would allow for a per-SP/per-user 
    84 "configuration", though admittedly it is not particularly elegant....It appears to work well with my sandbox. 
    85  
    86 I should add that I am primarily focused on SPs that do not send an 
    87 explicit request for authentication contexts. 
    88  
    89 Thanks, 
    90  
    91 Scott K