Hi,

MFA complicates all this. The driving force for supplementalAuthentications
> is that 3.5.x only records the _first_ authentication, even if a renew has
> subsequently occurred. The renewed authentication is simply discarded which
> is not what we want. Here's the problem case with that behavior:
>
> 1. User attempts to access service A with no existing CAS session.
> 2. User authenticates to CAS with username/password and gains access to
> service A.
> 3. User attempts to access service B, which imposes requirement to use a
> particular high-security credential other than username/password.
> 4. User is redirected to CAS and reauthenticates with high-security
> crednetial.
> 5. The original authentication is used for preparing the service ticket
> validation response, and any LOA or other attribute that indentifies the
> credential used would reflect username/password.
> 6. Access to service B is denied even though user authenticated with
> requisite credential.
>

OK. I see the use case.

The supplementalAuthentications property was created to store all the
> authentications that occur during an SSO session in order to support
> policy-based approaches to retrieving a particular authentication; for
> example "first one," "most recent," or something else. Storing all
> authentications allows us to implement the correct behavior for the case
> above.
>
> Based on my analysis we cannot use chainedAuthentications for that purpose
> since it's related to proxy chains and we want to keep the two orthogonal.
>

Agreed. I think they are orthogonal. We have a
*chainedAuthentication*where the first authentication is from user
credentials and next
authentications are from proxies. With LOA, we could have more user
credentials generating more authentications which then go to the *
supplementalAuthentications*.

An easy fix would be no to returned *supplementalAuthentications* with *
chainedAuthentications* just to keep the use of these *
supplementalAuthentications* where it needs to be : with supplemental
credentials [1] and to check if the policy is satisfied [2].

Are we in line ? So I can open a JIRA and propose the change.

Thus, I'm wondering if the right split for a future version would be to
have *userAuthentications* on one side (the first authentication of the
current *chainedAuthentications* and all *supplementalAuthentications*) and
*proxyAuthentications* on the other side (the other authentications of the *
chainedAuthentications*). What do you think ?

Thanks.
Best regards,
Jérôme


[1] :
https://github.com/Jasig/cas/blob/master/cas-server-core/src/main/java/org/jasig/cas/CentralAuthenticationServiceImpl.java#L291
[2] :
https://github.com/Jasig/cas/blob/master/cas-server-core/src/main/java/org/jasig/cas/CentralAuthenticationServiceImpl.java#L565

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev

Reply via email to