[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] SAML enhancement proposal from NSN
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]