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

["Abendroth, Joerg (NSN - DE/Munich)" <joerg.abendroth@nsn.com>]

Hi all,

I'll add some little structure so that my response keeps the
readability.

1. "New Protocol"

From a developers point of view, there definitely IS a difference
between "adding" a new SAML message consisting of already existing
building blocks or adding a completely new protocol with own bindings,
structures, processing rules, identifiers, and maybe even other
transports. With an extension to SAML (by adding the new message), the
already existing code can be reused.
And getting it deployed is not a so big effort: The SPs and IdPs have to
communicate to each other what they support anyway. If an IdP supports
the new SAML "messages", the SP can use them. If does not - it's ok,
too. If an SP does not support the AttributeManagement - it's not even a
problem, because then it just would not send them.
I do not think that the argument "that's too much work for me" is a good
reason for not doing something reasonable.

2. LDAP and update

LDAP is built on a tree-like directory structure. To be able to modify a
node, you of course have to know the structure of the directory (because
elsewise you would not be able to traverse it and specify *which* node
you want to modify).
Maybe, "update" is not completely enough and there exists a need for
"deleting" an attribute, you are right.
Nevertheless "update" is not a privacy risk, if the IdP defines proper
policies, which attributes can be modified by which service and for
which user. These policies have to be agreed on by the SP and IdP, of
course. But that's exactly the same as for the "read" - the
AttributeQuery.
If an IdP supports SP specific attibutes (which means: attributes that
are only visible to exactly one SP), it sure makes sense that the SP can
modify these attributes (they "belong" to him anyway).
By agreeing on possible values for each attributes, the privacy risk
gets eliminated. The IdP then has the task to check these values.

3. Partial errors

If there are some attributes that are logically bound to each other and
have to be updated in one transaction, they could be transmitted in one
message marking it as transactional. By returning the old values, it
gets obvious, that the transaction failed and there was an error. It
makes sense to send an error description in the
SAMLResponse-Status-Fields.

If the attributes are not logically bound and may fail or succeed one by
one, it is also enough to return the new (or old) values, because then
the SP is able to check which of the values have succeeded. 
I do not see a burden here.

4. Sharing data, Authorization and concurent updates

If the updated attributes are SP specific, the attributes are neither
shared nor will exist a need to look at concurrent updates or
authorization besides the already existing one (that also applies to all
other SAML messages/protocols).
If a shared attributes shall be able to get updated by multiple SPs, the
IdP has to define and enforce his own policies (who can and who can
not). But that's also the same as for the "read" operation. (regarding
the authorization).
If we have a concurrent update: All databases lock a record before
updating it and unlock it afterwards. This way "concurrency" is
eliminated, because now the updates are always serialized and the later
one will override the previous one - that's standard behaviour.
One could now think about marking an attribute as "may not be modified
until..." - but then that's a policy that has to be enforced by the IdP
(because the database will not be able to do this). Nevertheless I can
not imagine a case, where this scenario can take place for a shared
attribute.

Common: If an IdP decides to support modifying the attributes, it will
have to implement the policies, etc. anyway - no matter of which
"protocol" is used. If this then results in poor implementation, it's a
pity for the company because they employed the wrong persons, but not a
reason for standardization to define a good idea or do it not. If that
was a reasonable argument, a lot of protocols would not exist. I assume,
a lot of WS-* protocols would not even exist, because if you look at the
internet forums, people complain that they are too complex for them. But
they DO exist, they work good and secure, because there are other
developers who can understand and deal with the specs.

Finally, as you wrote "The inability to implement good, uniform,
scalable
authz in directories is one of the drivers for SAML's existence, IMHO" -
i completely agree. And that's a major argument *for* introducing it to
SAML and not to use a different protocol.

-- Markus and Joerg


-----Original Message-----
From: ext Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Wednesday, September 30, 2009 8:04 PM
To: Nguyenphu, Thinh (NSN - US/Irving); 'OASIS SSTC'
Cc: Guenther, Christian 1. (NSN - DE/Munich); Abendroth, Joerg (NSN -
DE/Munich)
Subject: RE: [security-services] SAML enhancement proposal from NSN

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