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: RE: PassThruAuthNMayHarmInterop


> From: Evan Prodromou [mailto:evan@outlook.net]
> ...
> I think you're ignoring the role played by the attribute authority in
> the domain model. It seems to me -- and I may be way off here -- that
> per our domain model, one sample scenario would go something like
> this:
> 
>         1. The user passes a user name and password to an entity
>            acting as an Authentication Authority -and- as an Attribute
>            Authority.

This is exactly the step where we've lost interop. Most SAML-based systems,
and certainly all the password or RADIUS-based Web SSO solutions, are going
to need some way to log in to that initial authentication authority. As long
as that protocol is not standardised, there is a significant part of every
solution that is not vendor-independent.

What this means is that vendors who build SAML "clients"; that is,
applications that make use of SAML services without implementing them
internally, can't _quite_ make their systems generic. Once you have the
authentication assertion, the rest of your interaction with a SAML
infrastructure is vendor-neutral, and could be handled by a single client
implementation.

However, the initial login phase, where the user presents login data to
create the initial authentication assertion, is still going to be
vendor-specific. That means that every vendor of SAML infrastructure still
needs to worry about creating plugins to all the applications they want to
support - the plugin is simpler, since it only needs to handle login, but
you still need to build one for IIS, and iPlanet, and WebLogic, and
WebSphere, and Apache, and so on, and so on. As the number of supported
applications increases, every vendor is going to suffer from the increased
development, maintenance, test, and support costs.

In one of the better of all possible worlds, the entire life cycle from
login to PEP-PDP decision would be handled by a standard protocol, so that
vendors could take a reference client implementation and build systems to
work with any SAML infrastructure.

 - irving -


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


Powered by eList eXpress LLC