On the WebAuth Website Access Request Form simply select the “Require NetID+” checkbox. Users will be required to use DuoSecurity second-factor authentication, after successfully authenticating with their NetIDs.

On the SIA Shibboleth Access Request page simply select the “Require NetID+” checkbox on the form when submitting your Shibboleth access request. Users will be required to use DuoSecurity second-factor authentication, after successfully authenticating with their NetIDs.

On the SIA Shibboleth Access Request page simply select the “Require NetID+” checkbox on the form when submitting your Shibboleth access request. Users will be required to use DuoSecurity second-factor authentication, after successfully authenticating with their NetIDs.

NOTE: When initially configuring your Shibboleth Service Provider, make sure to retrieve the “shibboleth2-netidplus.xml” configuration file in lieu of the standard “shibboleth2.xml” configuration file, as this version of the file contains a configuration element required for NetID+ interoperability (you will still need to name the file “shibboleth2.xml” when deploying the file in your Shibboleth SP configuration directory (/etc/shibboleth or C:\opt\shibboleth-sp\etc)

On the WebAuth or Shibboleth access request forms you will see a field labeled “NetID+ Groups”. This field allows you to specify any number of groups (comma-separated) – defined and managed in UITS’ Grouper system – which are required to use NetID+ when accessing your service; users not in any of these groups will not be prompted for NetID+ authentication. If you enable NetID+ authentication without specifying any groups (i.e., you leave the groups field blank), then NetID+ will be enforced for all users.

The WebAuth ticket validation mechanism determines at the time of service ticket validation – based on the service provider ID (“service” URL) parameter, and the user’s EDS entry – whether the service ticket was required to have originated from a NetID-only (single factor) or NetID+ (dual-factor) authentication sequence. If the required authentication sequence was not used, WebAuth will reject the service ticket validation attempt with a element similar to the following:

		       
<cas:authenticationFailure code='UNACCEPTABLE_AUTHENTICATION_METHOD'>
     Ticket XXX did not fulfill the required authentication method &#039;duo&#039;.
</cas:authenticationFailure>		    

		   

Shibboleth, by extension (since it delegates authentication to WebAuth), will return a SAML error under the same circumstances.

If you need to drive an application-level decision based on NetID+ authentication status, you can do that in both WebAuth and Shibboleth:

WebAuth

The “cas:authenticationSuccess” element will contain an element called “cas:authn_method”, with a value of “duo” when NetID+ authentication has been performed. For example:

		   
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
    <cas:authenticationSuccess>
        <cas:user>joeuser</cas:user>
              <cas:attributes>
                    <cas:dbkey>119999999955</cas:dbkey>    
                    <cas:activestudent>0</cas:activestudent
                    <cas:activeemployee>1</cas:activeemployee>
                    <cas:emplid>12345678</cas:emplid>                    
            </cas:attributes>
            <cas:authn_method>duo</cas:authn_method>    
    </cas:authenticationSuccess>
</cas:serviceResponse>
		   

Shibboleth

If NetID+ authentication has been performed, a Shibboleth attribute (typically accessible as an HTTP environment variable or header) called “Shib-Authentication-Method” will be present ,and its value will be the string “http://shibboleth.arizona.edu/authnMethod/2FA”