authentication attributes

[Baron Fujimoto]

Are the set of CAS authentication attributes documented somewhere? If you test logins using /cas/login, we can see, for example, the following set of authentication attributes:

credentialType, clientIpAddress, samlAuthenticationStatementAuthMethod, authenticationDate, bypassMultifactorAuthentication, authenticationMethod, authnContextClass, successfulAuthenticationHandlers, serverIpAddress, userAgent

Some of them are straightforward, such as clientIpAddress, authenticationDate, serverIpAddress, userAgent; but it would be helpful to have some formal documentation on exactly what the others are.

For example, suppose a client wanted to verify that MFA was actually used. If we only supported Duo for MFA, is it sufficient to simply check, say, successfulAuthenticationHandlers for the value "DuoSecurityAuthenticationHandler", or do you also have to verify bypassMultifactorAuthentication = "false"? Or is there another "correct'' way to do this?

Bonus: we also use the shib-cas plugin to front our Shibboleth IdP deployment with CAS. Any pointers to how we can make use of these authentication attributes to define comparable attributes on the Shib side would be appreciated.

--

Baron Fujimoto <ba...@hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

[Baron Fujimoto]

FWIW, we've noted that the shib-cas plugin supports the REFEDS MFA profile, which suggests perhaps it's using the conditional expression (authn_method=mfa-duo && authnContextClass=mfa-duo) as the basis for its MFA assertions. Can anyone confirm this?

<https://github.com/Unicon/shib-cas-authn3#handling-refeds-mfa-profile>

[Ray Bon]

Baron,

I am planning to change the shib-cas plugin to use delegated SAML authn (shib delegating to cas) to solve this problem.

Right now if a shib service requires MFA, the user will have to duo in both cas and shib.

Ray

On Tue, 2022-07-05 at 10:11 -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.

-- 

Ray Bon

Programmer Analyst

Development Services, University Systems

2507218831 | CLE 019 | rb...@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.

[Baron Fujimoto]

Hi Ray,

I'm hoping there's a distinction between a profile requiring MFA, and being able to assert whether it was used or not for the AuthN. As I understand it, (I think), a REFEDS profile may require MFA, and the AuthN would fail if it were not used. That's fine, and if that's what the REFEDS MFA profile requires as a feature, no problem.

But in addition to directly supporting the REFEDS MFA profile, we'd also like alternative ways to assert whether MFA was actually used for the user's AuthN. Scott Cantor has said on the shib-users mailing list that SAML should use AuthnContextClassRef to signal authentication types. So it would be good if we can do this the "right" way and use AuthnContextClassRef appropriately in the IdP.

However, I anticipate that we may need to integrate with SPs that can not or will not use  AuthnContextClassRef. For them, we would like to define a new attribute we could provide to SPs that would reflect the actual usage of MFA for a user's AuthN.

Scott has suggested that the AuthN attributes are presumably available via request variables (if not already more conveniently via shib-cas – but I didn't see that documented). As well as,"Accessing request information via a script is handled by injecting shibboleth.HttpServletRequest as a customObject-ref into the scripted definition(s). That gives you anything available on the HttpServletRequest interface. Controlling the type of authentication from an external login method is handled by setting the right Java request attribute when the external authn method finishes work [1] and passes control back to the IdP so either the CAS plugin can do that or it has to be modified to do so." But at this point I'm out of my depth on how to do any of that, and I don't have any good examples to work from with the current shib-cas.

For now I've followed the instructions shib-cas REFEDS MFA instructions referenced earlier, but I'm unsure how to test this in a test environment where the (test) IdP is not included in the InCommon aggregate metadata that a REFEDS SP may be relying on. The Shibboleth KB has a suggestion, but I'm not sure how apropos it is for the shib-cas configuration.

<https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1474297850/Supporting+the+REFEDS+MFA+Profile>

--
- 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+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/8111d119e970cc251a7998aeccea3de7bec0ce65.camel%40uvic.ca.