mace-opensaml-users - RE: Help wanted on single sign on
Subject: OpenSAML user discussion
List archive
- From: Scott Cantor <>
- To: 'Bob Daly' <>,
- Subject: RE: Help wanted on single sign on
- Date: Mon, 10 Nov 2003 20:55:48 -0500
- Importance: Normal
- Organization: The Ohio State University
> I've read the SAML bindings doc, and I'm having
> trouble envisioning how SAML assertions persist across
> SAML compliant apps and services.
Well, let's be clear on the fact that the profile document defines exactly
two profiles, both of which do web SSO by transiting a special kind of
authentication assertion from source site to destination site.
Anything else is outside the spec. The SAML binding/protocol defines a way
to issue SOAP queries for matching assertions, but it doesn't address why
you would do that or what you do after you get the response, which seems to
be the gist of your question.
> Let's say I have a
> web app that issues an AuthenticationQuery for some
> subject to an issuing authority service and then
> receives an assertion. The assertion will function as
> a security token to then access, for example, an XACML
> based policy decision point.
XACML tends to deal more in attributes, but that's beside the point...
> Are assertion documents usually stored by the web app
> (using cookies or perhaps a db?) Are they also stored
> by the issuing authority? Does the Shibboleth doc
> describe use cases that would clarify this?
The Shibboleth doc describes our use case, which is SSO with attribute
exchange, but nothing else.
There really isn't an answer to the question of what people "usually" do.
There is no such pattern of usage. Whether and how you store an assertion
depends on why you got it, under what conditions, and what you plan to do
with it. Whether that usage is "secure" in the sense of accomplishing
something in a secure fashion again is highly profile-specific.
Whether an authority stores the assertions it issues is up to the authority,
and also depends on what the assertions are for.
I'd note that SAML security tokens aren't some kind of drastically new
thing. The things SAML represents in XML are largely the kinds of things
represented by lots of other kinds of tokens. The more interesting way to
approach this kind of question is to think about the problem without
focusing on the kind of token. What's the security problem to be solved?
Once you define that, the reasons for using SAML vs. some other technology
become a technical consideration.
-- Scott
---------------------------------------------------mace-opensaml-users-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/
---------------------------------------------------mace-opensaml-users--
- Help wanted on single sign on, abrar khan, 11/09/2003
- RE: Help wanted on single sign on, Scott Cantor, 11/10/2003
- RE: Help wanted on single sign on, simmi sharma, 11/10/2003
- Unsubscribing from <mace-opensaml-users> list, Steve Olshansky, 11/10/2003
- RE: Help wanted on single sign on, Bob Daly, 11/10/2003
- RE: Help wanted on single sign on, Scott Cantor, 11/10/2003
- RE: Help wanted on single sign on, simmi sharma, 11/10/2003
- RE: Help wanted on single sign on, Scott Cantor, 11/10/2003
Archive powered by MHonArc 2.6.16.