RE: [security-services] Stateless Conformity To SAML

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

Yes, my mistake - mgmt not mapping.  I was looking for the return status
to the mgmt request to indicate "unwilling" and wound up in the mapping
section inadvertently.  So, is the status for "unwilling to write ID
change" still InvalidNameIDPolicy, or is it something more meaningful I
did not find?

Mike 

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

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

NameID Mapping or NameID Mgmt? I assume you mean the latter. NameID
Mapping is a read operation. NameID Mgmt is always a write to
something/somewhere.

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

I think we're talking about different stuff here. But yeah, as a
deployer you don't have to support any feature in the spec unless you're
partnering with somebody that expects you to. That's a contract thing,
not a conformance thing.

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

No, that wasn't really my point, but it probably amounts to the same
thing.
I'm saying I might drop in a dummy implementation via a database that
nobody could/would use for production to implement the write operations,
and I could pass a conformance test. But I'd much rather say "I support
this profile *if* you provide an implementation of my plugin interface
to implement the persistent write operations into your account data".
That's a more honest statement and a lot more useful to you.

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

Again, NameID Mgmt, but yes. It is outside the spec. How could it be
otherwise? We're talking about changing account names used by
applications to do any of a million things, stored in potentially any
number of ways.

-- Scott