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


Subject: RE: [security-services] Analyzing cost of MTI features


> If I am a vendor delivering an application which will consume SAML 2.0
> assertions, I can probably assume access to a read-only identity store
> (e.g., via JNDI) but little else. As things stand such a component would
> not be eligible for conformance as both SP and SP Basic require support
> for name identifier update/termination protocols (update of an enterprise
> data store).

I'm not fully convinced this is true (the latter point, I mean). It's not
clear to me that in terms of conformance testing, any Liberty products were
probably tested in a mode that could reasonably be called "update of an
enterprise data store". Maybe I'm wrong, but I guess I had assumed that this
was mostly one of those things you tend to stub out behind an interface.
Meaning, if you *have* such capability in a deployment, sure, go ahead and
bridge it, but if you're just testing for conformance, you mock it up and
demonstrate that you're processing the messages in proper fashion.

And in terms of what you deliver as a product, I just don't see the extra
work here. Account linking scenarios simply can't live in a vaccuum. There
are clearly points of integration that relieve the SAML implementation from
having to solve the whole problem itself. The state comes from behind those
points of integration, not inside the implementation.

I don't want to make this a war over who can implement what the easiest, but
FWIW, I just don't see the added complexity here.

-- Scott





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