Re: [cas-user] CAS 6.5 w/ Duo MFA, was MFA actually used?

[Baron Fujimoto]

Thank you for all the replies. I think we're still using the Duo
integration method to integrate with CAS that was prevalent circa CAS 5.x
(Duo SDK?). I think at the time we finally upgraded to CAS 6.x, the Duo
universal prompt stuff was still documented as not quite fully baked and
"coming soon", so we deferred implementing that and stuck with what
appeared to be successfully backwards compatible. It seems like with the
newer methods we'd have more information available.

Because our MFA is opt-in, we've enabled it globally and not on a
per-service basis. We've also currently leave the MFA requirements to the
business logic in the applications themselves, but are trying to find ways
to make that information for them more authoritative.

These replies give us options to investigate and consider for future
deployments. Mahalo!

On Fri, Jul 29, 2022 at 12:31 PM Ray Bon  wrote:

> Baron,
>
> We have been setting mfa in the service definition; some services are
> mandatory, others optional. Users can opt to enrol in duo in another
> internal application (where they can update other personal data, etc).
>
> I have experimented with (but not used in prod):
>
> # Specify the regular expression pattern to trigger multifactor when
> working with a single provider.
> # Comment out the setting when working with multiple multifactor providers
> # cas.authn.mfa.global-principal-attribute-value-regex=urn:mace:uvic.ca:
> university:duo_user
>
> # Activate MFA globally based on authentication metadata attributes
> #
> cas.authn.mfa.global-authentication-attribute-name-triggers=eduPersonEntitlement
> #
> cas.authn.mfa.global-authentication-attribute-value-regex=urn:mace:uvic.ca:
> university:duo_user
>
> Using the older style duo mfa [from within cas],the attributes are as you
> listed. When our user does not go through mfa, these attributes are set as:
>
> successfulAuthenticationHandlers:  [LdapAuthenticationHandler]
> credentialType:  [UsernamePasswordCredential]
> authenticationMethod:  [LdapAuthenticationHandler]
> no authContextClass
>
> With the newer universal prompt, these attributes exist:
>
> duoAuthCtxTxId  176187f6-63c6-453f-9e1a-43b1b50dd961
> duoAuthResultStatus  allow
> duoAuthCtxApplicationName  Web SDK Universal prompt
> duoAuthCtxReason  remembered_device  (user_approved  on first login)
> authnContextClass  mfa-duo
> duoAuthCtxAccessDeviceIp  xxx.xxx.xxx.xxx
> duoAuthCtxResult  success
> duoAud  DI...
> duoAuthCtxAccessDeviceLocationCity  Victoria
> duoAuthCtxFactor  remembered_device (duo_push on first login)
> duoAuthCtxTimestamp  1659132374
> duoAuthCtxAccessDeviceLocationState  British Columbia
> duoIss  https://api-duosecurity.com/oauth/v1/token
> bypassMultifactorAuthentication  false
> successfulAuthenticationHandlers  DuoSecurityAuthenticationHandler
> duoSub  rbon
> duoAuthCtxAccessDeviceLocationCountry  Canada
> duoAuthCtxUserKey  DU...
> credentialType  DuoSecurityUniversalPromptCredential
> authenticationMethod  DuoSecurityAuthenticationHandler
> duoIat  1.659132375E9
> domain  uvic.ca
> duoPreferredUsername  rbon
> duoExp  1659135974
> duoAuthTime  1659132374
> duoAuthCtxEventType  authentication
> duoAuthResult  allow
>
> So lots to choose from.
>
> Ray
>
> On Fri, 2022-07-29 at 09:44 -1000, Baron Fujimoto wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
> We're currently using CAS 6.5 with Duo for MFA. While the MFA itself
> works, we're trying to find some way of determining whether MFA was
> actually used during a user's authentication.
>
> MFA is not mandatory for our users, and they must opt-in and enroll
> themselves with Duo. We can see that when a user authenticates, there is a
> set of promising CAS authentication attributes available. e.g.:
> - successfulAuthenticationHandlers: [DuoSecurityAuthenticationHandler]
> - credentialType: [DuoSecurityCredential]
> - authenticationMethod: [DuoSecurityAuthenticationHandler]
> - authnContextClass: [mfa-duo]
>
> However, these attributes appear to be assigned the same values
> whether the user is enrolled in Duo or not – and thus are presented
> with the MFA requirement during their login. Therefore, there doesn't
> appear to be anything in these attributes that allows us to distinguish
> whether MFA was actually invoked/required/used for the user's
> authentication.
>
> FWIW, this is how we're currently enabling MFA for CAS in cas.properties:
> cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
>
> We've looked at the available multifactor authentication triggers, but
> none of the attribute-based triggers seem appropriate since I think they
> rely on local information about the principal, and not something
> authoritative from Duo or about the actual CAS authentication flow that was
> used. Perhaps there's a way using the REST method with the Duo Auth API
> /enroll_status or /preauth endpoints, but that sounds kind of 

Re: [cas-user] CAS 6.5 w/ Duo MFA, was MFA actually used?

[Ray Bon]

Baron,

We have been setting mfa in the service definition; some services are 
mandatory, others optional. Users can opt to enrol in duo in another internal 
application (where they can update other personal data, etc).

I have experimented with (but not used in prod):

# Specify the regular expression pattern to trigger multifactor when working 
with a single provider.
# Comment out the setting when working with multiple multifactor providers
# 
cas.authn.mfa.global-principal-attribute-value-regex=urn:mace:uvic.ca:university:duo_user

# Activate MFA globally based on authentication metadata attributes
# 
cas.authn.mfa.global-authentication-attribute-name-triggers=eduPersonEntitlement
# 
cas.authn.mfa.global-authentication-attribute-value-regex=urn:mace:uvic.ca:university:duo_user

Using the older style duo mfa [from within cas],the attributes are as you 
listed. When our user does not go through mfa, these attributes are set as:

successfulAuthenticationHandlers:  [LdapAuthenticationHandler]
credentialType:  [UsernamePasswordCredential]
authenticationMethod:  [LdapAuthenticationHandler]
no authContextClass

With the newer universal prompt, these attributes exist:

duoAuthCtxTxId  176187f6-63c6-453f-9e1a-43b1b50dd961
duoAuthResultStatus  allow
duoAuthCtxApplicationName  Web SDK Universal prompt
duoAuthCtxReason  remembered_device  (user_approved  on first login)
authnContextClass  mfa-duo
duoAuthCtxAccessDeviceIp  xxx.xxx.xxx.xxx
duoAuthCtxResult  success
duoAud  DI...
duoAuthCtxAccessDeviceLocationCity  Victoria
duoAuthCtxFactor  remembered_device (duo_push on first login)
duoAuthCtxTimestamp  1659132374
duoAuthCtxAccessDeviceLocationState  British Columbia
duoIss  https://api-duosecurity.com/oauth/v1/token
bypassMultifactorAuthentication  false
successfulAuthenticationHandlers  DuoSecurityAuthenticationHandler
duoSub  rbon
duoAuthCtxAccessDeviceLocationCountry  Canada
duoAuthCtxUserKey  DU...
credentialType  DuoSecurityUniversalPromptCredential
authenticationMethod  DuoSecurityAuthenticationHandler
duoIat  1.659132375E9
domain  uvic.ca
duoPreferredUsername  rbon
duoExp  1659135974
duoAuthTime  1659132374
duoAuthCtxEventType  authentication
duoAuthResult  allow

So lots to choose from.

Ray

On Fri, 2022-07-29 at 09:44 -1000, Baron Fujimoto wrote:
Notice: This message was sent from outside the University of Victoria email 
system. Please be cautious with links and sensitive information.

We're currently using CAS 6.5 with Duo for MFA. While the MFA itself works, 
we're trying to find some way of determining whether MFA was actually used 
during a user's authentication.

MFA is not mandatory for our users, and they must opt-in and enroll themselves 
with Duo. We can see that when a user authenticates, there is a set of 
promising CAS authentication attributes available. e.g.:
- successfulAuthenticationHandlers: [DuoSecurityAuthenticationHandler]
- credentialType: [DuoSecurityCredential]
- authenticationMethod: [DuoSecurityAuthenticationHandler]
- authnContextClass: [mfa-duo]

However, these attributes appear to be assigned the same values whether the 
user is enrolled in Duo or not – and thus are presented with the MFA 
requirement during their login. Therefore, there doesn't appear to be anything 
in these attributes that allows us to distinguish whether MFA was actually 
invoked/required/used for the user's authentication.

FWIW, this is how we're currently enabling MFA for CAS in cas.properties:
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo

We've looked at the available multifactor authentication triggers, but none of 
the attribute-based triggers seem appropriate since I think they rely on local 
information about the principal, and not something authoritative from Duo or 
about the actual CAS authentication flow that was used. Perhaps there's a way 
using the REST method with the Duo Auth API /enroll_status or /preauth 
endpoints, but that sounds kind of fraught (even if possible).

Is there something else we may be overlooking that would help us achieve our 
goal?
--
Baron Fujimoto mailto:ba...@hawaii.edu>> ::: UH Information 
Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

--

Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca

I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional territory 
the university stands, and the Songhees, Esquimalt and WSÁNEĆ peoples whose 
historical relationships with the land continue to this day.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web 

Re: [cas-user] CAS 6.5 w/ Duo MFA, was MFA actually used?

[Mike Osterman]

We are also non-mandatory MFA at present, and doing what Richard suggests.
If they are a memberOf the AD group in question, they are required to Duo,
regardless of service.

# Active Directory LDAP connection
cas.authn.attributeRepository.ldap[0].attributes.memberOf=mfaAttribute

cas.authn.mfa.globalPrincipalAttributeNameTriggers=mfaAttribute
# MFA Group
cas.authn.mfa.globalPrincipalAttributeValueRegex=CN=MFA,OU=Something,DC=school,DC=edu

On a side note, we've talked about limiting some services to only users
that are MFA'd (Apparently Transact will require if we want to use their
Mobile Credential smart phone NFC functionality) and are looking towards
service access strategies via the same group membership attribute:
https://apereo.github.io/cas/6.5.x/services/Configuring-Service-Access-Strategy.html

On Fri, Jul 29, 2022 at 1:46 PM 'Richard Frovarp' via CAS Community <
cas-user@apereo.org> wrote:

> How are you triggering MFA / Duo? You likely only want to trigger Duo on a
> local attribute and setup the integration to force Duo always. If you are
> leaving it up to Duo to decide if the user is enrolled and bypass if not,
> the old Duo Web integration couldn't tell you what happen, just that they
> got past Duo. 6.5 should be using the new OIDC method, and it was supposed
> to return back more detail so you could make security decisions. So
> something there isn't working?? Here's my writeup about the Duo Web
> integration problems:
> https://www.frovarp.dev/2019/03/24/ambiguous-response-in-duo-web/
>
> But in any event, I'd stick them in a group if they have to MFA and
> trigger Duo off of membership in that group, always enforcing MFA to happen
> on that integration.
>
> On 7/29/22 14:44, Baron Fujimoto wrote:
>
> We're currently using CAS 6.5 with Duo for MFA. While the MFA itself
> works, we're trying to find some way of determining whether MFA was
> actually used during a user's authentication.
>
> MFA is not mandatory for our users, and they must opt-in and enroll
> themselves with Duo. We can see that when a user authenticates, there is a
> set of promising CAS authentication attributes available. e.g.:
> - successfulAuthenticationHandlers: [DuoSecurityAuthenticationHandler]
> - credentialType: [DuoSecurityCredential]
> - authenticationMethod: [DuoSecurityAuthenticationHandler]
> - authnContextClass: [mfa-duo]
>
> However, these attributes appear to be assigned the same values
> whether the user is enrolled in Duo or not – and thus are presented
> with the MFA requirement during their login. Therefore, there doesn't
> appear to be anything in these attributes that allows us to distinguish
> whether MFA was actually invoked/required/used for the user's
> authentication.
>
> FWIW, this is how we're currently enabling MFA for CAS in cas.properties:
> cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
>
> We've looked at the available multifactor authentication triggers, but
> none of the attribute-based triggers seem appropriate since I think they
> rely on local information about the principal, and not something
> authoritative from Duo or about the actual CAS authentication flow that was
> used. Perhaps there's a way using the REST method with the Duo Auth API
> /enroll_status or /preauth endpoints, but that sounds kind of fraught (even
> if possible).
>
> Is there something else we may be overlooking that would help us achieve
> our goal?
> --
> Baron Fujimoto  ::: UH Information Technology Services
> minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
> --
> - Website: https://apereo.github.io/cas
> - Gitter Chatroom: https://gitter.im/apereo/cas
> - List Guidelines: https://goo.gl/1VRrw7
> - Contributions: https://goo.gl/mh7qDG
> ---
> You received this message because you are subscribed to the Google Groups
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-user+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL0-uwSJhTVCLXBRSUPhfDWSHFUn1xT%3DjSJJw8vwWXdp9g%40mail.gmail.com
> 
> .
>
>
> --
> - Website: https://apereo.github.io/cas
> - Gitter Chatroom: https://gitter.im/apereo/cas
> - List Guidelines: https://goo.gl/1VRrw7
> - Contributions: https://goo.gl/mh7qDG
> ---
> You received this message because you are subscribed to the Google Groups
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cas-user+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/de4b2e35-06a5-20a2-e3dd-58960bfb7159%40ndsu.edu
> 

Re: [cas-user] CAS 6.5 w/ Duo MFA, was MFA actually used?

['Richard Frovarp' via CAS Community]

How are you triggering MFA / Duo? You likely only want to trigger Duo on 
a local attribute and setup the integration to force Duo always. If you 
are leaving it up to Duo to decide if the user is enrolled and bypass if 
not, the old Duo Web integration couldn't tell you what happen, just 
that they got past Duo. 6.5 should be using the new OIDC method, and it 
was supposed to return back more detail so you could make security 
decisions. So something there isn't working?? Here's my writeup about 
the Duo Web integration problems: 
https://www.frovarp.dev/2019/03/24/ambiguous-response-in-duo-web/


But in any event, I'd stick them in a group if they have to MFA and 
trigger Duo off of membership in that group, always enforcing MFA to 
happen on that integration.


On 7/29/22 14:44, Baron Fujimoto wrote:
We're currently using CAS 6.5 with Duo for MFA. While the MFA itself 
works, we're trying to find some way of determining whether MFA was 
actually used during a user's authentication.


MFA is not mandatory for our users, and they must opt-in and enroll 
themselves with Duo. We can see that when a user authenticates, there 
is a set of promising CAS authentication attributes available. e.g.:

- successfulAuthenticationHandlers: [DuoSecurityAuthenticationHandler]
- credentialType: [DuoSecurityCredential]
- authenticationMethod: [DuoSecurityAuthenticationHandler]
- authnContextClass: [mfa-duo]

However, these attributes appear to be assigned the same values 
whether the user is enrolled in Duo or not – and thus are presented 
with the MFA requirement during their login. Therefore, there doesn't 
appear to be anything in these attributes that allows us to 
distinguish whether MFA was actually invoked/required/used for the 
user's authentication.


FWIW, this is how we're currently enabling MFA for CAS in cas.properties:
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo

We've looked at the available multifactor authentication triggers, but 
none of the attribute-based triggers seem appropriate since I think 
they rely on local information about the principal, and not something 
authoritative from Duo or about the actual CAS authentication flow 
that was used. Perhaps there's a way using the REST method with the 
Duo Auth API /enroll_status or /preauth endpoints, but that sounds 
kind of fraught (even if possible).


Is there something else we may be overlooking that would help us 
achieve our goal?

--
Baron Fujimoto  ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google 
Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL0-uwSJhTVCLXBRSUPhfDWSHFUn1xT%3DjSJJw8vwWXdp9g%40mail.gmail.com 
.


--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/de4b2e35-06a5-20a2-e3dd-58960bfb7159%40ndsu.edu.

[cas-user] CAS 6.5 w/ Duo MFA, was MFA actually used?

[Baron Fujimoto]

We're currently using CAS 6.5 with Duo for MFA. While the MFA itself works,
we're trying to find some way of determining whether MFA was actually used
during a user's authentication.

MFA is not mandatory for our users, and they must opt-in and enroll
themselves with Duo. We can see that when a user authenticates, there is a
set of promising CAS authentication attributes available. e.g.:
- successfulAuthenticationHandlers: [DuoSecurityAuthenticationHandler]
- credentialType: [DuoSecurityCredential]
- authenticationMethod: [DuoSecurityAuthenticationHandler]
- authnContextClass: [mfa-duo]

However, these attributes appear to be assigned the same values whether the
user is enrolled in Duo or not – and thus are presented with the MFA
requirement during their login. Therefore, there doesn't appear to be
anything in these attributes that allows us to distinguish whether MFA was
actually invoked/required/used for the user's authentication.

FWIW, this is how we're currently enabling MFA for CAS in cas.properties:
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo

We've looked at the available multifactor authentication triggers, but none
of the attribute-based triggers seem appropriate since I think they rely on
local information about the principal, and not something authoritative from
Duo or about the actual CAS authentication flow that was used. Perhaps
there's a way using the REST method with the Duo Auth API /enroll_status or
/preauth endpoints, but that sounds kind of fraught (even if possible).

Is there something else we may be overlooking that would help us achieve
our goal?
-- 
Baron Fujimoto  ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAjLUL0-uwSJhTVCLXBRSUPhfDWSHFUn1xT%3DjSJJw8vwWXdp9g%40mail.gmail.com.