Re: [security-services] Session use-case (was Re: [security-services] SSTCf2f minutes...)

[Anthony Nadalin <drsecure@us.ibm.com>]

John, sorry for the delay,

>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

>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

>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

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

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

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

>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

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

>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

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122