[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Stateless Conformity To SAML
[Nick] So, a SAML product/component is part of a system of (here) name ID mgt. It may carry out that job through it's own devices or through integration with some other (standard, say) facilities. Is that the base sense? [/Nick] Exactly. SAML components may be delivered at a finer granularity than at the "enterprise level". There may be a business application that consumes SAML for authenticating users, a perimeter device which is a SAML producer (take a look at the Juniper announcement I sent out earlier today), there may be a kiosk which consumes SAML and delivers movies and so on right upto the proverbial SAML-driven toaster. All of these components may jointly implement ID-FF IdP/SP functionality as part of a larger infrastructure but often the individual components are limited by design and architecture in their ability to write to enterprise data stores. They would not be able to obtain conformance as defined in conformance-03 today. [Nick] And that beyond that there may be a name ID mgt participant that wishes to be entirely stateless (well, single state, Prateek's #1), with no sense of changing state of its initial name ID mgt state as internalized, not even through associated facilities? [\Nick] Enterprises have quite complex provisioning systems that ensure directories get updated from various data sources, including data feeds received or sent to partners. This ensures that identity stores are synchronized and updated. Applications or devices will then bind to the identity store to access the most current data (name identifier, local names, partner identity etc). The key point here is that writing to an identity store is controlled by systems quite distinct from the SAML producer or consumer. Often these systems are required to be reliable and/or transactional. One should note that the SAML 2.0 protocol is neither. [Nick] Interpreting this from the Liberty Alliance interoperability conformance perspective effort, I'd guess we'd expect, in the base sense, that the product/component represent itself as "Liberty Alliance Interoperable" conformant to name ID mgt only in conjunction with details on the specific additional facilities needed. Thus the component is a plug in, or feature, or embedded capability, or some such. LAP has several cases of this. (Scott wins that bet!) This just demonstrates how conformance is carried out in one way (as Scott mentions) and the deployment and marketplace claims are represented in complimentary by different ways (and ... how the requirements of a conformance program might help to moderate that). But the second case is one apart. This seems to me to fail the test of an appropriate *general* name ID mgt participant. As I suggested in the call, it might be useful to consider the perspective from a third party, not the SP, not the IdP, but rather an auditor of the network state. Here, after an update, the auditor will expect the "single state" participant to respond with the updated state information. The only mitigation for failure would be, e.g., metadata that informs the auditor of the 'special' configuration of the 'single state' participant. To me this suggests we have the requirement that any product or component claiming conformance to name ID mgt profiles must be able to demonstrate state awareness, however effectively marshalled (Prateek's #2, #3, etc). [/Nick] I would have to say this is a very stringent requirement to apply to *every* SAML-aware application. This is the crux of the matter. The issue is whether we are willing to take into account the manner in which software components that consume or generate SAML are constructed today. [Nick] And the additional possibility that we create a conformance profile for this "Stateless assertion consumer/generator" which can require they participate the name id mgt, but only at that "stateless" level. My own intuition is that this latter case, although a bit interesting, will find only specialized use. This is a bit at odds with another intuition I have, that there will be many more IdPs in this world that we might now think. But I suspect that folks engineering such "stateless" participants will engineer the environment in which the devices work to respond more like the "base" sense above ... failure of particular assertions will invoke network rerouting. In this case we have to ask whether they (or the SSTC) needs a special conformance class/role/fred/rolf at all. [\Nick] I am not sure I agree with the assessment that such components or applications "will find only specialized use". IMHO, this is not a matter of intuition but of awareness of current practice in the field. I invite you to view the large and growing field of security appliances including some that generate and consume SAML today. Further, speaking as representative of a vendor with a considerable history in federation, our products are often delivered as "enforcement points" on various touchpoints that are quite capable of consuming SAML but cannot write back to persistent store.