> I don't like the idea to have different security contexts.

It's good to consider the impact of multiple security contexts.  For
simplicity I was imagining that the entire SSO session would be
upgraded to the authenticated credential with highest LOA, but upon
further consideration it's probably a matter of security policy and we
might want to have a policy framework to allow configuring behavior.

> So I would be more informative :
> - if you have been already authenticated, your username input field would be 
> filled with your previous authentication username

Sounds reasonable to identify the principal of the current SSO session.

> - your filled username input field would not be editable and a link (next to 
> the input field) would be available to logout and login again.
> This way, we would avoid some authentication desynchronization and we would 
> not have to deal with overriding or discarding authentications.

Logging out is exactly what we hope to avoid.  We use SLO extensively,
and logging out would have the effect of terminating a number of
application sessions in order to upgrade the security context to
access a more secure service.  That's a non-starter for us and in
general for anyone that uses SLO extensively.

> Shouldn't we start our reflexion by use cases approach ?

I tried to articulate one: how does the client articulate an LOA
demand to the server and how does the server assert that the demand
was met.  I mostly wanted to float the use of renew=true as a
least-effort way to accomplish this, but discussing the details seemed
interesting to me.

I'm going to actually spend some time prototyping this and see what
shakes out.  I feel like we've done a lot of talking ab out
multifactor and LOA and I simply want to get concrete.  If anyone
wants to collaborate, that would be great.  In any case I'll share
whatever shakes out of my work even if it's a dead end.

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

Reply via email to