Support for renew=1 when using delegated auth to Azure AD?

[Dennis Sjögren]

Hi,

I've been experimenting with Delegated Authentication to Azure AD (via pac4j) and it works like a charm. The last day or so I've been searching for an answer to whether renew=1 can be propagated to the authorize call to Azure AD somehow. If I'm not mistaken, a parameter of prompt=login could be the way to go.

When I test from a CAS enabled app, renew=1 seems to be forcing a new request to Microsofts authorize endpoint, but since I already have an active session in Azure, I'm not prompted for my credentials again.

I've been looking into the CAS codebase for a configuration hint or something. I've been a full time developer for 25+ years, unfortunately not in Java - so needless to say, I'm not being particularly successful. :)

So my question is: Is it possible to force re-validation of credentials using renew=1 when delegating to Azure AD?

Regards,

Dennis

[Pablo Vidaurri]

try renew=true

It should work as cas will force reauthenciation again.

[CAS Community]

It generally depends on what version of CAS (and pac4j) you run. Most recent versions can handle protocol translations, such that renew=true is ultimate translated to prompt=login or max_age=0 or something like that. 

[Dennis Sjögren]

Yes, I'm sorry, a typo. The app is sending renew=true.

/Dennis

[Dennis Sjögren]

Currently running v6.5.2. Planning on upgrading to latest 6.6.x soon.

The thing is, initially CAS does the right thing with renew=true, i.e. redirecting to the authorize endpoint in Azure. My goal is that renew=true should translate to prompt=login. Is there anything *I* can do to influence this process? Besides learning Java and fixing it myself (which, depending on the complexity, I'm actually considering). :)

However, I think I might have another problem.

I did a "poor man's" fix by adding this:

cas.authn.pac4j.oidc[0].azure.custom-params.prompt=login

Then when my app is requesting re-auth (via renew=true), Delegated Authentication redirects to Azure and credentials are requested (forced by my setting above). However, then I get this:

PROTOCOL_SPECIFICATION_VALIDATE_FAILED

[Cas20WithoutProxyingValidationSpecification] is to enforce the [renew] CAS protocol behavior, yet the assertion is not issued from a new login

So my suspicion is that even if I could translate renew=true to prompt=login in Delegated Authentication somehow, I would get stuck on this validation. Correct me if I'm wrong, but this must be an error? I mean, CAS is obviously aware of renew=true, but when Delegated Authentication returns the ST seems to be generated from the previously created TGT anyway? This could of course be by design - considering that there might not be a way for CAS to know if the delegated authentication client did request re-validation of credentials or not. That way, it would probably be better to send max_age=0, but that requires that CAS can validate the auth_time claim...

I'm so close to getting this setup to where I want it to be... but this might just be a blocker. Gonna go look up the price of IntelliJ IDEA now. :)

Regards,

Dennis

[Dennis Sjögren]

So... Running IntelliJ IDEA on a 2019 MacBook Pro with a 2,.6GHz 6-Core Intel i7 is... interesting. Having it directly in your lap is not recommended. Listening to the fans constantly at 5000 rpm is not as fun as it sounds. :) (And being a developer in a completely different ecosystem doesn't help.)

Anyway, I found out that if you manage to set the ForceAuthn request attribute in the getRedirectionAction method in DelegatedClientAuthenticationRedirectAction.java (cas-server-support-pac4j-webflow), the resulting redirect to Azure will have max_age=0 as a query parameter. Yay!

I've been experimenting with setting a query parameter (for the clientredirect call) in the resolve method in DelegatedClientIdentityProviderConfigurationFactory.java (cas-server-support-pac4j-core). This then gets carried over to the aforementioned getRedirectAction method via the transient session ticket. This works but I'm not sure if this is more of a "hack" or if it's nearing something that would be acceptable to submit as a PR.

Anyway. Back to experimenting.

Regards,

Dennis

[Jérôme LELEU]

Hi,

The version 6.5.x no longer accepts contributions (except security patches): https://apereo.github.io/cas/developer/Maintenance-Policy.html

So don't worry about submitting a PR.

Thanks.

Best regards,

Jérôme

--
- 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/dbda6d6b-14b3-4d3d-96ce-d22f19186338n%40apereo.org.

[Dennis Sjögren]

I'm experimenting in the master branch at the moment. Wasn't planning on trying to submit anything to an old branch...

/D