RE: [security-services] Stateless Conformity To SAML

["Mishra, Prateek" <pmishra@netegrity.com>]

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