OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [security-services] Protocol extension for role change


> Am 08.11.2016 um 17:58 schrieb Cantor, Scott <cantor.2@osu.edu>:
> 
>> Does anybody know of a similar use case, and which design was selected?
>> Any other comments?
> 
> I think it's simpler to leave it to the application.

The applications don't have the data. In this federation all privilege management is with the user home organization except a handful applications.

> Increasingly people seem to use separate accounts now for this sort of thing. It's like we're back to 1990 and nobody remembers why we stopped using multiple accounts for everything. I don't really like either model (multiple accounts or choosing roles), and would prefer just seeing step-up or reauthentication used if the application wants to guard something more closely (e.g. like a role switch).

A number of agencies does have separate accounts for roles. While re-authentication is transparent for Kerberos backends, this is not good for 2FA. And the usability issue remains: without SLO users end up with different contexts across applications after logging in with a different user in a particular application. 
 
> 
> I can't tell from your description, but it sounds like you mean for a role change (which SAML doesn't define anything about, roles don't exist in the standard) to actually imply a single logout, which we know in practice doesn't work anyway.
> 
> It seems like a waste of time to engineer a solution to cause logout when that won't actually work. Why bother with that piece?

I don't think that it the key obstacles of SLO apply here. The UI-problems from SLO are not relevant, because the activation of a the change is an application function. Users are trained for this. The success status reporting may be a problem in (rare?) cases where the SP becomes unresponsive, but a later request would succeed. The only consequence then is a different role and privilege set, usually leading to data not found errors. Moreover, front-channel SLO implementation is required by the deployment profile anyway. 


- Rainer



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]