/Cas20WithoutProxyingValidationSpecification/ class that checks if the
chained authentications has just one element [3] which is false (2
elements are returned : one as the authentication and one more from the
/supplementalAuthentications/).
That's why it fails.
I don't think that it's the expected behaviour.
Agreed, though I can't say at the moment what the expected behavior
should be. My gut reaction is that I missed some components in my
analysis of some of the new MFA capabilities;
Cas20WithoutProxyingValidationSpecification is likely one of them.
Although I reviewed this source code (and especially the
/supplementalAuthentications/ property), I'm not sure to understand why
we need it eventually, as we have the same authentication in the
authentication and in the supplemental authentications.
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.
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.
I plan to begin integrating the current 4.0 snapshot into our overlay
some time this month, at which time some of these issues will become
clearer to me. If you or anyone else has further insight before then,
I'd be happy to discuss.
M
--
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
