| | 1 | |
| | 2 | == Two-factor Authentication== |
| | 3 | |
| | 4 | Two-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.] |
| | 5 | |
| | 6 | The UA Identity Provider is being 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 "accept" 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 | |
| | 11 | 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. |
| | 12 | |
| | 13 | A 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. |
| | 14 | |
| | 15 | == Invoking two-factor authentication == |
| | 16 | At least two means of invoking two-factor authentication are envisioned: |
| | 17 | |
| | 18 | (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. |
| | 19 | |
| | 20 | (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. |
| | 21 | |
| | 22 | == Implementation == |
| | 23 | |
| | 24 | UA IAM is currently (2014Q1) working with Duo Security to provide this capability for two-factor authentication. We have deployed a proof of concept in a non-production environment that demonstrates the integration with some production services. Interested UA members may contact iam@alaska.edu for details and to participate in the pilot. |
