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] | [Elist Home]


Subject: PassThruAuthNMayHarmInterop



Folks,

In yesterday's minutes, Eve wrote:

> Stephen suggested this new issue: PassThruAuthNMayHarmInterop:
> There may be interoperability implications of our decision not to pass
> through credentials.

Since I had to leave the call before we got to this (did the call get that
far?), I guess I should explain. 

Omitting pass through authentication from SAML's scope means that SAML fails 
to meet the goal of specifying a muti-vendor interoperable PEP/PDP protocol. 

This also means that application developers cannot write the PEP side with 
the expectation of working sensibly with authorization vendors on the PDP 
side, similarly authorization vendors will have to continue to write PEP 
plug-ins etc for each and every application (and version! yuk!).

I think that that's a very bad outcome.

Why is it the case? Well, the lack of pass through authentication 
means that each PEP will have to decide how to handle each authentication
scheme itself. For some schemes (PKI based ones) this isn't a problem, but 
for other schemes to work requires administrative co-ordination of the
authentication and authorization information in a (logically) single
repository. 

To give an example, think about a "typical" scenario: using the password 
associated with an LDAP entry to authenticate a user and storing some
authorization information related to that user (there may well be 
additional authorization information elsewhere) in the same LDAP entry.
The decision made at the F2F means that both the PEP and PDP *independently*
have to access the same LDAP entry. This causes a number of problems, e.g.:-

- Can't protect the LDAP entry attributes using the password as the PDP
  never gets the password.
- PEP and PDP (or possibly PDP "admin") need co-ordinated configuration to map 
  from user name to host/port & entry name (non trivial in many cases, won't
  happen in a multivendor environment).
- LDAP acls for admininstration stuff might be harder (both the PEP and PDP
  administrative users probably need write access).
- Adding a user in one go becomes much harder.
- Firewall issues may become harder.

The bottom line seems to be that the only way to sensibly handle such
cases (which we all already support in our products) is that the same
vendor has to produce both PEP and PDP (and probably add pass through
authentication to the "standard" SAML PEP/PDP protocol in a vendor
specific manner).

In summary, I believe the decision taken, was mistaken, since it means 
that SAML fails to meet the real PEP/PDP protocol requirement which, as 
with all protocols, is multi-vendor interoperability.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


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


Powered by eList eXpress LLC