Re: [security-services] Session use-case

[John Kemp <onezero@bcn.net>]

Anthony,

See comments and (hopefully further clarifications) below:

On Monday, Nov 17, 2003, at 12:23 US/Eastern, Anthony Nadalin wrote:

> John, sorry for the delay,
>

Not a problem - we're all busy.

>> Are you implying SSO between the services? If not, what properties 
>> exist
> such that the user sees this as a single service? Are there additional
> requirements other >than SSO and a shared session among the  services 
> that
> imply "looking like a single service" to the user?
>
> This is much like a transaction, requestor -> end point -> service ->
> service ... where you want all sub session to look like one logical 
> session
> thus the need for some sort of coordination (linking identifier) effort
> that has semantics

Yes, I'm just trying to get the specifics of what "looking like a 
single service" means in this case. Perhaps a concrete example might be 
in order:

I'm using my corporate travel service TravelTheWorld.com to book a 
flight and a hotel for my business trip to Mongolia. I log on to the 
travel agent's site, am authenticated, and receive a "global" session 
for doing business not only on TravelTheWorld.com, but on their airline 
and hotel partners' sites too. I check my flight options and come up 
with days and times that work for me, but I want to check the hotel 
situation before I finish booking my flight, so I navigate over to 
TravelTheWorld.com's hotel partner. I figure out my hotel room 
situation, and feel comfortable with the whole deal, so I go back to 
the flight site, and want to commit myself to the flight booking.

So, the session contains two currently uncommitted transactions (a 
flight booking, and a hotel booking). As the user, what I specifically 
want is:

1) Seamless authentication across those sites (SSO) so I don't need to 
log on separately to both sites.
2) My session at all sites to exist until I have successfully committed 
both the flight and the hotel booking transactions.

All entities involved in this scenario use a shared session identifier, 
but can account things separately, based on this unique ID (unique in 
that it was provided by TravelTheWorld.com's session authority for John 
Kemp). Some central session authority (which could be any of the 
entities in the transactions, but is most naturally close to 
TravelTheWorld.com) provides the central session. In my understanding 
of your terminology, this scenario crosses "realms". Both of the 
"child" services have what amounts to an individual session for the 
user, and the session authority can account centrally for the provision 
of that session.

So, what is specifically different about what you are suggesting? What 
is the actual use-case that requires a parent/child session linkage?

>> How is this not covered by having a shared session (as defined in the
> current requirements document) between SSO-enabled services, supplied  
> by a
> central session >authority?
>
> The need for a central session authority is somewhat overkill and can 
> be a
> point of failures, now if what you are saying is that any entity can 
> be a
> central session authority then that may a compromise

Yes, any entity can in theory be a central session authority. Some 
entities may be more natural than others in that role.

>> Who is correlating the "accounting and auditing information" (if not 
>> the
> session authority), and what is this information comprised of -  
> length of
> time using the >application, or number of "hits"? Something  else?
>
> More like a "context" and thus the issue I have with the 
> "authentication
> context", so items like (1) expiration, (2) identifier, (3) 
> coordination
> services address

So, in the case of a session that is utilized by more than one service, 
the authority that provided the session would set this information, and 
be responsible for maintaining and logging such data. A session 
authority may also provide sessions for one service only, and thus 
would mostly naturally be located closely coupled with the service 
itself, a different endpoint offered by the same entity.

By 'expiration' I assume that you mean what we have to date called 
'timeout'. This and 'identifier' I would consider central to the notion 
of session, and are thus more than just contextual. A session authority 
would be ultimately responsible for co-ordinating and accounting these 
items for a session.

>> Is this a requirement - ie. individual session ids linked to some 
>> parent
> with another session id? What information would be required about the
> related services?
>
> It's not a mandatory requirement but should be an option, and I would
> gather that only the related service address (EPR) be included.

This would introduce the concept of a parent and child relationship 
between sessions. Although I can see that this might be a legitimate 
requirement, I'm still not clear on a use-case that isn't covered by 
the current thinking that would require such a thing, and it seems like 
it might introduce additional complexity to this subject, so I would be 
interested in a specific use-case where you think it is required (or at 
least provides a better - under some definition of better - experience 
for involved parties).

>> Well, session ID + NameIdentifier (for example) would be unique to the
> session and the combination of subject + provider. It's not clear to me
> that the session ID >provided to the service provider by the session
> authority would need to be *globally* unique in and of itself. It 
> would  be
> unique within the realm of all >services for which the authority was
> providing sessions, and the uniqueness could possibly even be bounded  
> by
> some time period.
>
> The problem I have here is that a session may cross realms and there 
> needs
> a way to do this.

I agree, and I believe that there will be a way to do this.

>> Are you implying that the identity of the "user" of service B is 
>> "service
> A", or is it still "User"? Does the session authority issue a session 
> with
> a subject of >"user", or a subject of "service A"?
>
> The identity is still the "user" but with the notion that "Service A" 
> is
> propagating, so its a combination (for audit reasons)

I guess I'd call that a "proxied" session. Again, I'd like to see the 
actual use-case that would require such a thing. Of course, with the 
current model, one could imagine there being a hierarchy of session 
authorities, where a session authority could be a service that requires 
a session for usage by services that require sessions? ;)

>> Is a session shared between service A, service B and service C for the
> same subject (user) not sufficient for this? What do you mean by an
> "instance" in this >case?
>
> The point here is that its not a shared session. The term "instance" 
> means
> that the user may have many sessions going and each parent session is 
> a new
> instance and not a shared session

That is already possible. Either one has a shared session for several 
sessions, or a session for only one service. The issue that I'm trying 
to address is whether there needs to be a parent session for the 
situation where a user has a session only for the one service (where 
presumably the parent session is global and the child is local, right?) 
OR whether having TWO sessions - one from a local session authority for 
the local service, and one from a global session authority - is 
required.

>> The session authority would know that it had issued a shared session, 
>> and
> it would know who the audience (both the provider and subject) was for 
> the
> session, so >the session authority could presumably account session 
> usage.
> Is your suggested requirement that we state that the session authority
> should account for all >sessions that they dispense?
>
> Yes they would need to do this assuming that a any entity can be a 
> session
> authority.

OK, agreed.

>> In summary, I believe that the requirements for this use-case (as 
>> stated
> so far) are already covered in the current requirements document 
> (available
> at
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/
> 3659/draft-sstc-session-management-02.pdf ).
>
> Well that is what triggered my usecase, so I don't believe its 
> covered, as
> global session are not equivalent to what is in the usecase I proposed

So, to summarize:

1) You want to ensure that global sessions and local sessions are all 
logged, including timeout and session identifier values. I believe this 
will be covered as much as it can be by the solution. Session 
authorities will certainly be held responsible for doing this. Although 
no amount of normative text can enforce such logging, one can imagine 
that it would be good risk management to do so.
2) You want to see a model in which linkable parent and child sessions 
may be present in some service environment. In theory, I could see this 
covered by having a hierarchy of session authorities, where one session 
authority requires a session provided by another session authority, in 
order to hand out sessions to other services. This could probably be 
made possible. In practice, however, I'd still like to see a use-case 
described (as above for the travel booking case) where this is 
absolutely necessary, as it does have the potential to make the system 
more complex.

Cheers,

- JohnK