[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