OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Abendroth, Joerg (NSN - DE/Munich) wrote on 2009-10-01:
> 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.

Note that I wasn't advocating a completely new protocol, I was examining the
question of whether adding support for an existing protocol was a vastly
larger effort than supporting a new SAML extension, and I don't really think
it would be.

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

The issue isn't "rolling it into place" but getting support for it in
implementations to begin with. Presumably you want multiple implementations,
or there'd be no reason to standardize it.

> I do not think that the argument "that's too much work for me" is a good
> reason for not doing something reasonable.

Except that "it's too hard" is the siren song of every reinvented standard.
It's a big reason people do (or don't do) a lot of things.

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

Only superficially. At the end of the day, an entry has a key (the DN) and
that's it. The protocol doesn't require anything else, to my knowledge.

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

Yes, and that's a lot of work to support, and poor support leads to some of
those risks.
 
> 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).

No, that's not the case. Ownership is orthogonal to release policy and the
scope of an attribute.

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

I'll have to disagree there, I don't believe that a requester of an update
should have to go comparing values to figure out what worked and what
didn't.

Transactions are also complicated to support, so you get into some
interesting territory there.

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

I think there's a lot of work involved with supporting and dealing with
partial success conditions, regardless of where the work gets shifted.

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

A lot of protocols that exist are ignored by the market or disappear because
they get no adoption.

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

I can find any number of reputable people to dismiss and ridicule WS-* for
you, so that's a good example of why complexity definitely matters here.

As for whether they work well, we'll have to disagree profoundly on that
point. I think they're too complicated, and being that I worked heavily on
SAML and it's often viewed as being too complex, that says something to me.

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

The question is whether introducing it to SAML will change that. I'm not
sure that it will.

I guess what I think overall is that there needs to be some commitment from
implementers to make this worth doing. If it's just writing a spec, I think
we're risking a lot of wasted effort.

-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]