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