[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] SAML enhancement proposal from NSN
[NSN] Aftter further analysis of these two other solutions and our proposal, we can summarize the following:
SPML defines two bindings: SOAP or file. It is not able - like SAML - to be transported via HTTP Post or Redirect, nor does it support the concepts of including an issuer (the entity that created the request), privacy (encrypting parts of the request), security (digitally sign parts of the request), or similarities. It is thought for enabling two entities that are closely related to each other (e.g. enable an IdP to communicate with a database, enable two SPs to exchange information about their data within the *same domain*).
It further does not contain concepts like validity intervals (valid between two dates), expiration, etc. It is to be seen as database synchronization protocol. (Compare it to SQL, but with LDAP/X509 structure and a little bit more… formal :-) )
CARML is a protocol to enable applications to communicate with each other. It is an administration protocol with a huge variety of possible methods, that all have to be understood by both parties. Further, they have to have a "common understanding" on policies, each others concepts, etc. That's not the case in
NSN use cases where we have an external service provider, operates by maybe a small company, and the IdP, operated by a telco that wants to "hide" ist internals and of course also ist database, structure and concepts.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.
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..
[NSN] Only the fields that need to be updated will be in the request. Subjects can neither be changed nor updated, because there already exists a message protocol in SAML for doing this. The issuer is the one that creates the message - why should this be changed ? Finally - because the message is signed by the issuer, no fields can be changed on the transport between SP and IdP.
Attributes shall not be added "on the fly" because this would create a privacy and security risk. The attributes that may be stored have to be previously agreed on by both parties (the same way as they were agreed for the attribute query). Conditions and Validity intervals are a good idea and worth an extension of the idea.
Partial errors are signaled by containing the "old" values in the response.
If there is a field within the request that this is a transaction and therefore atomic, the response would not be a "Success" with old values (for the failing attributes) but a "Failure" with a SAML error code. (As already defined by the standard). 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.)[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.
-----Original Message-----
From: Nguyenphu, Thinh (NSN - US/Irving) [mailto:thinh.nguyenphu@nsn.com]
Sent: Tuesday, September 15, 2009 1:42 PM
To: OASIS SSTC
Cc: Guenther, Christian 1. (NSN - DE/Munich); Abendroth, Joerg (NSN - DE/Munich)
Subject: [security-services] SAML enhancement proposal from NSNHello,
My name is Thinh Nguyenphu from Nokia Siemens Networks. My colleague and I are summiting two new contributions, which its propose new enhancement to SAML.
Enclosed contributions are SAML Attribute Management Protocol, and SAML Name Identifier Protocol.
<<SAML Name Identifier Protocol.ppt>> <<SAML Attribute Mgt Protocol.ppt>>
I kindly request to be included in next TC SS agenda, September 22.Best Regards,
ThinhThinh Nguyenphu
Mobile: +1 817-313-5189
thinh.nguyenphu@nsn.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]