Stateless Conformity To SAML

["Dana Kaufman" <dkaufman@forumsys.com>]

I agree with Prateek,

I have to agree with what Prateek mentioned.  I think it important to
allow stateless components to claim conformity to SAML 2.0.  If you are
on the network edge and want to consume or generate SAML assertions
based on secure communicate to a backend store, you should be able to
claim conformity as an SP or IdP.  For these products, persisting state
information could have negative impact on performance and security.
Also, a lot of web service actions are done in a stateless environment
with no browser interaction.

Dana S. Kaufman
VP of Product Management
Forum Systems, Inc.
Tel: (781) 788-4232
E-Mail: dkaufman@forumsys.com
Visit http://www.forumsys.com
 

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com] 
Sent: Wednesday, July 28, 2004 5:33 PM
To: Nick Ragouzis; security-services@lists.oasis-open.org
Subject: [security-services] Analyzing cost of MTI features (WAS Minutes
for 20-July 2004 SSTC con-call (official and focus call))

Nick,

As suggested in the previous call by Scott, the best way to proceed is
to
start with ID-FF 1.2 SCR and analyze the various MTI features. So my
next
steps are to get a version of our conformance document out with the
relevant
ID-FF 1.2 SCR materials. In the interim, here a few thoughts on the
relative
"cost" of MTI features.


One way to understand the relative complexity of an MTI feature is to
ask
the question:

(1) Can a stateless component implement this feature?
(2) Does it require the component to utilize long-term persistent
storage?
(3) Does it require the component to update external enterprise data
stores?

And so on. As this requirements list grows longer, it becomes
increasingly
difficult for independent components to implement the feature and claim
conformance.

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

In a different direction, most web access management systems restrict
state
to client-side cookies. Avoiding explicit retention of session state
(requires long-term persistent storage) within the access management
system
is generally considered important for reasons of scalability. However,
such
a system would not obtain IdP conformance as it could not process a
back-channel logout message. I believe this comment was also made by
Steve
Anderson during the previous conference call.


Needless to say it is upto the TC decide whether these issues need to be
reflected in the conformance matrix.


- prateek



-----Original Message-----
From: Nick Ragouzis [mailto:nickr@enosis.com] 
Sent: Tuesday, July 27, 2004 1:39 PM
To: security-services@lists.oasis-open.org
Subject: RE: [security-services] Minutes for 20-July 2004 SSTC con-call
(official and focus call)

A follow-up to the conformance focus call topic:

> - Nick: We still have the question of whether the NameID mgmt 
> protocols are MTI in basic [in IdP].  What's the process for 
> reaching resolution.

What I actually asked was about criteria, not process. Something
like: What's the CRITERIA we will consider in choosing between our 
options in this case?

Our conversation gave rise to an economic criteria: Will SAMLv2.0
be meant only for the 5 largest vendors?

Presumably this implies that the name id management (NIMgt) 
protocols present a significant hurdle to implementer resources -- 
in knowledge, time, or costs, for example. I wonder: How we can 
get more information on this? 

In asking around I've been unable to locate anyone who can offer 
any representative case study that would allow us to make the 
marginal analysis for the NIMgt part over the resources required 
to completely build and deliver WebSSO without NIMgt. Does anyone
have one to offer? (Or even a rough (say) CoCoMo or FPA of either 
part?) Clearly if this turns out to be a significant burden over
the base, then the question is answered.

But if we are to admit economic criteria, then I think we are
also called on to consider the wider marketplace dynamics of 
the decision: How is economic advantage derived, pursued and 
maintained in the identity space?

I think in this case we'll find that putting NIMgt protocols as
MTI in basic conformance offers tangible marginal advantage to 
the smaller players ... both among vendors and among deployers.

The crux of this conclusion derives from three dynamics:
1. the usual dynamics of standards processes (smaller players 
   derive more benefits relative to their market position); and,
2. the dynamics of identity-based economics (it is a bandwagon 
   marketplace, where broad interlinking at the highest levels 
   of value-add are crucial to preventing market breakdown due 
   to forces that mandate that customers choose winners); and,
3. claims of conformance can offer advantages, but these 
   advantages are not uniformly distributed, with deployers
   and the smaller vendors garnering relatively more benefits. 

In this way, larger players deploy the resources to implement
the technology that suits their de facto architectures, and 
smaller players must follow ... with deployers choosing among 
these.

If this de facto architecture does not include NIMgt protocols 
the smaller players (especially deployers, but also vendors) 
will have a significant challenge in adding NIMgt services where 
none already exist ... and the larger players are significantly 
advantaged.

However, when (if) the larger players become sensitive to 
claiming conformance (from, say, deployer pressures), then 
specifying NIMgt protocols as MTI in basic will bestow on the 
smaller players (deployers, and vendors too) independent 
opportunities to offer and participate in NIMgt services. 

Where we admit economic criteria in conformance profile 
decisions, these arguments have some application to other 
decisions ...  but the NIMgt protocols are the among the 
highest order of cases due to its role in interlinking.

Hope this helps. :-)

Best,
--Nick


> -----Original Message-----
> From: Philpott, Robert [mailto:rphilpott@rsasecurity.com] 
> Sent: Friday, July 23, 2004 09:30 AM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Minutes for 20-July 2004 SSTC 
> con-call (official and focus call)
> 
> 
> Official meeting minutes compliments of Eve.  Focus call 
> minutes compliments of Eve and Rob.
> 
...
> - Nick: We still have the question of whether the NameID mgmt 
> protocols are MTI in basic.  What's the process for reaching 
> resolution.
> 


To unsubscribe from this mailing list (and be removed from the roster of
the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/l
eave
_workgroup.php.



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/l
eave_workgroup.php.