OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [saml-dev] Introduction & Question about the "heaviness" of S AML

Title: RE: [saml-dev] Introduction & Question about the "heaviness" of SAML


I think you may have an incorrect assumption.

SAML does not specify how to use the assertions, or how long they are valid for.

For example, in the SAML SSO use case (as typified by the Burton interoperability tests with SAML browser artifact profile), the assertions are intended to be "single use" documents that expire in minutes. Their sole purpose in this case is to propagate user identity and/or attributes across a trust boundary (e.g. cross site).

Once the assertion has been propagated, it us up to the receiving site (the "destination" site) to create a local session, and to decide which attributes it trusts (based upon the trust relationship with the "source" site).

So, in this case, it is not at all a "multi-function permission slip that can be ported around by the user and used anywhere" and there is no need to revoke these assertions because they expire in minutes.

Again, SAML does not specify how to use the assertions, only what the are, and how to propagate them. You can use it in any manner that suits your needs.

I would be happy to discuss this further if you like.

John Herendeen

-----Original Message-----
From: Adam Theo [mailto:theo@theoretic.com]
Sent: Wednesday, November 13, 2002 12:30 AM
To: Mark Wilcox
Cc: saml-dev@lists.oasis-open.org
Subject: Re: [saml-dev] Introduction & Question about the "heaviness" of


I've sat down (virtually) with my co-developer, and he carefully
explained why he thinks SAML is not good for our project. He is not
against SAML in general, he just believes that the "SAML way" doesn't
fit in with the "PingID way". And now that he has explained why in
detail, I agree with him. I'd like to lay out his (now our) points, to
make sure we are correct about our assumptions about SAML, and why it
doesn't fit into our design very well.

 From what we have read, we assume that SAML is for creating "documents"
that are signed by an authority and in essence say "The bearer of this
document has been authenticated by me. They are who they say they are.
If you trust me, then you should trust them.". These signed documents
cannot be revoked or altered because the reader has no obligation to
contact the authority to see if it is true. The reader assumes that as
long as they can make sure the document was signed by the authority
(such as through a PGP key or other algorithm), then what the document
says should be true, too.

Also, the document can be used anywhere the authority is trusted. It's a
multi-function permission slip that can be ported around by the user and
used anywhere, instead of services needing to formally establish
relationships with the user on a case-by-case basis.

I'm not saying these are bad things. It's good that SAML is doing this,
because many organizations need this type of mechanism. I'm just now
starting to realize that it's not the way we want to do things, if my
assumptions are true.

So, I'm hoping for people to help me out in clarifying what I have
assumed above. Thanks.

Mark Wilcox wrote:
> Hi Adam,
> So is this going to dove-tail back into anything with Jabber?
> If you're looking at SSO (which SAML can definitely play a part) you should
> check out what we're doing in Internet 2 with Shibboleth
> (http://middleware.internet2.edu/shibboleth) and WebISO
> (http://middleware.internet2.edu/webiso).
> Possibly you could also look into what's going on in with PingID
> (http://www.pingid.com).
> I would advise getting more involved with one of those scenarios than trying
> to do your own. The last thing the world needs is another SSO option since
> one of the things preventing more wide-spread adoption is that there's too
> many non-interopable options now.
> I've also made the argument at the recent I2 meetings that everyone focuses
> on authentication when it's authorization that's the kicker. It's relatively
> easy to pass around SSO authentication tickets (which is why there's so many
> freakin' different options out there). The more criticial & harder piece to
> solve is standardizing authorization information which is the point that
> SAML is trying to solve.
> SAML isn't perfect. But nothing is. And it's got a lot more traction than
> anything else out there.
> If you have questions about I2 stuff -- you can email me offline as well at
> mark.wilcox@webct.com.

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC