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 20:05 schrieb Cantor, Scott <cantor.2@osu.edu>:
> 
>> 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 don't understand why a user would be confused by a role switch in one application not affecting others. Seems like that would be what I'd expect.

There are both expectations and we do not have useful data about the distribution. But take this use case:
A group of municipalities jointly operate the Building and Construction Office, which are legally separate Authorities. Officers working in this office assume a role for each municipality, in certain cases they also assume state level authority. They process usually case by case. The working time per case may exceed session timeouts (typically 30 min). In each role the officer exercises authority for the specific municipality, with the signatures etc. set by the role passed by the IDP. Even the lookup of personal data in a government register requires  this role for audit purposes. 

The officer is primarily working on cases, not applications. The officer will use multiple applications with SSO. When switching to a new case from a different agency all settings must change. (Except interruptions by customer calls).

The real difficulty is that role changes may occur implicit, by virtue of SP-timeout and re-authentication with the IDP's previous session. A user would loose track of contexts when a role change would occur per application.

BTW, this use case is actually implemented this way in our legacy SSO system.

> 
>> 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.
> 
> If SLO doesn't work, then the application never gets notified at all.

Yes, there is a residual risk. But it is mitigated by the fact that user notification will work well, as the logoff-and-close-the-browser behavior is not relevant here.

- Rainer


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