RE: [security-services] SAML enhancement proposal from NSN

["Scott Cantor" <cantor.2@osu.edu>]

Nguyenphu, Thinh (NSN - US/Irving) wrote on 2009-09-29:
> Of course, storing attributes at IdP could be handled by another protocol.
> The drawback is that both parties (IdP and SP) have to be extended by
> another protocol and maybe also their specific contexts (authentication,
> protocol specific needs, etc.) - if SAML would support it, everything is
> already there.

I don't think there's any difference. A new SAML protocol is a new protocol.
The fact that there's some reuse doesn't really change that. It's still a
large amount of work to get it deployed, plus a new protocol would
inevitably require a lot of thought into getting it right, vs. existing
protocols that already have been through that work.
 
> NSN intention is to create a very simple and well understandable message
to
> alter SP specific or allowed common attributes of a user. This proposal is
> not trying to duplicate other cappabilities from CARML or SPML, such as
> read, find, search compare, add, delete. Because some of the these
> capablities already existed in the SAML like, read and find. The
marketplace
> is requiring an ease of implementation and reduction the network
complexity
> by not requiring to understanding the database structure and concept of
the
> IdP, reducing number of supporting protocols, etc..

I'm not known as an LDAP fan, but for the record I don't think LDAP cares
anything about the underlying database structure either. It's just "do this
stuff to this directory entry".

I'm also not convinced that it will be sufficient to only deal with
"update".

> Attributes shall not be added "on the fly" because this would create a
> privacy and security risk.

So do updates.

> Partial errors are signaled by containing the "old" values in the
response.

I don't think that's adequate at all. You need a fully thought out error
structure to deal with partial success, or atomicity (which can be hard to
implement). Either way it's a burden on one side or the other.

> Because our idea is about "service provider
> specific" updates, it is very unlikely to find "concurrent" updates. If
> there is one, the later one will override the previous one. (Like it is
the
> same for attribute requests etc.)

I think that's too limiting, personally. Theere's no intrinsic definition of
what separates an SP from another SP, and there all kinds of scenarios in
which multiple related systems function as separate SPs but share data.

> 3. Authorization is likely to be complex, involving not only fine
> grained access control and forms of delegation. (Nothing XACML can't
> handle of course.)
> 
> [NSN] We do not see these issues a problem, because it would not affect
the
> Attribute Management Protocol. And, it is already part of the standard.

I agree that it's not in scope of the protocol, but it would make people
very reluctant to implement, or result in poor implementations. I think LDAP
is a good example of how a simple system gets much harder once a proper
security model is added. The inability to implement good, uniform, scalable
authz in directories is one of the drivers for SAML's existence, IMHO. And
that's just for protecting read access. Here it's much harder.

-- Scott