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