Title: SAML enhancement proposal from NSN
Hello
Hal and et al,
Thanks
you for the comments. I hope that the
following the responses resolve your concern and clarify some of the
points. Please see the response under heading [NSN]
below.
Regards,
Thinh
From: ext Harold Lockhart
[mailto:]
Sent: Tuesday, September 22, 2009
10:06 AM
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
I have
significant concerns about the Attribute Management Protocol
proposal.
SAML
has avoided any kind of update protocol for good reasons. I am not ready to say
I oppose ANY such scheme, but there are a number of matters that need to be
considered.
1. The
proposal appears to duplicate functionality defined in other standards or open
proposals, including
SPML
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=provision
and
CARML. http://www.openliberty.org/wiki/index.php/ProjectAris
It may well be that this proposal provides necessary functionality
missing from any other specification or that there are reasons why doing it in
SAML is superior to any other approach, but this needs to be documented
explicitly.
[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..
2. The
semantics of updates in a distributed environment are always complex and
requirements and level of required support must be made
explicit.
Off
the top of my head:
What
are the semantics of the update? Exactly what fields in the assertion are deemed
to be being updated? Can a new Subject be added or only attributes be
updated? Can the issuer be changed? Validity Interval? other Conditions? Can
Attribute be added or only existing ones changed?
What
are the error semantics? How are partial errors handled and
signaled?
What
are the transaction semantics? Is the update atomic?
When
is the update expected to be visible? How does it interact with replication?
What about conflicting updates?
Is modify the only required action? What about Create? Delete?
[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.)
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.)
Authentication of the SP and likely the User is going to be a lot more
critical.
Is
control to the attribute/action level required?
At a
minimun, this scheme will make the IPD threat model a lot more
complex.
I am sure there are other issues as well, but I wanted to mention my
concerns prior to the call today.
[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.
Hal
-----Original Message-----
From: Nguyenphu, Thinh (NSN -
US/Irving) [mailto:]
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 NSN
Hello,
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,
Thinh
Thinh Nguyenphu
Mobile: +1 817-313-5189
