RE: [security-services] Stateless Conformity To SAML

["Beach, Michael C" <michael.c.beach@boeing.com>]

Many of us consuming companies are working hard toward centralized
identity management and therefore much prefer the "cause to be stored"
approach over the "stored" approach.  Also, many of us are very
concervative when it comes to what mechanisms we will allow to write to
our "stores".  So I see us being cautious about turning on NameIDMapping
functionality (although I expect we will see applicable scenarios as our
deployment expands).

So, if as Scott suggests as a deployer I have the option to negociate
NameIDMapping out-of-band, and as the Core spec allows I can return a
status of InvalidNameIDPolicy I can see this working for us.  Of course,
the negative is if NameIDMapping is MTI, and we chose not to use our
vendor's implementation of that, we will still pay for it in the end.

For those "cause to be stored" implementations, I see a bit vague
separation of duty between the implementor responsibilities and deployer
responsibilities.  Also, how a functional NameIDMapping actually works
on the backend in the "cause to be stored" environment may vary
substantially.  Seems an implementor needs to allow for the "stubbed
out" NameIDMapping function, but at the same time I don't think we want
to declare an implementation that is nothing more than a stub out
(always returning an InvalidNameIDPolicy) to be declared conformant.
Gee...so what exactly does the conformant implementor have to do in a
"cause to be stored" solution when I won't let him/her write to my
store?  Suppose I just turn it off and the implementation always returns
invalid.  Appears in the "cause to be stored" environment the real
functionality in NameIDMapping is outside of the spec.

Mike

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Friday, July 30, 2004 1:28 PM
To: 'Nick Ragouzis'
Cc: 'SAML'
Subject: RE: [security-services] Stateless Conformity To SAML

> I like your approach of thinking from the other view. I think, 
> however, it's a bad idea to conceive of a 'general' SP that claims 
> support for name id mgt but that cannot/doesn't actually store (or 
> cause to be stored) persistent records.

But "store" and "cause to be stored" are two fundamentally different
implementation strategies that are (as I understood it) exactly what's
at issue here.

I can implement a largely stateless system that implements the protocol
by "causing to be stored" the result of the messages. It's not up to me
to make it happen, and I can't be blamed if the deployer refuses to
implement the necessary write-back because he doesn't want to. Nor is
that non-conformant, but rather a deployment choice (as long as I return
an error when I'm asked to process the change and the write fails).

> > Where we would run into trouble, I think, is if an implementation 
> > stores persistent records of user federations but doesn't support 
> > Name ID Management (federation termination in particular).
> 
> Well put. This is one specific way in which the 'stateless'
> implementation is problematic, and for which its designers would 
> probably have to rely on failure modes ... which would seem to shorten

> the life of two important utilities of such a "device"
> (speed and independence).

But an implementation may well "support" persistent records of user
identities (I prefer that to the term federations) without "storing"
them.

Does conformance need to distinguish such a case? From your previous
note, it sounds like this was handled by making qualified statements of
conformance, but that seems to underline what conformance is supposed to
mean, and I didn't see any guidance in the SCR for how that works.

-- Scott


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/l
eave_workgroup.php.