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: Session use-case (was Re: [security-services] SSTC f2f minutes...)


Thanks for sending out the use-case. I copied the text below out of the  
supplied word document, to make commenting easier - see comments and  
questions inline:

> Use case examples relative to sessions
> This use case demonstrates the need to have sub sessions identified  
> under a parent session (top level) and single session linked to  
> multiple users
> Environment
> A may be composed of different services from different providers. For  
> the user this may still look like a single service.

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?

>  To correlate accounting and auditing information the different  
> sessions which are part of a service need to be linked together. This  
> can be achieved via session ids. Several alternatives for linking are  
> possible.
> One alternative would be the use of a common session id.

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?

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  

> Another alternative would be to use individual session ids for each  
> sub session, in combination with a binding function (or a binding  
> service) that would allow obtaining information about the related  
> services. In the accounting case it might not be necessary to link to  
> the session ID if there is a separate billing for each accounted  
> process.

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?

> A session id must be unique for each provider-user combination. This  
> means that each provider and user may have to create a piece of the  
> session id to guarantee that it is unique to it. It is also possible  
> that the provider creates the whole session id by using user and  
> provider information

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.

> Sample Use Cases
> User access service A, service A uses service B, service B uses  
> service C, and so on.

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"?

>  Each service usage is a separate instance, thus different sessions  
> but all must be accounted for as a single session with same user.

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 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?

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  
3659/draft-sstc-session-management-02.pdf ). Of course, I may not  
understand the use-case correctly or completely, in which case I would  
appreciate any clarification you could give me, or an even more  
concrete example that illustrates the case)\.


- JohnK

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