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 SAML

Adam -
I echo Prateek's remarks in an earlier response to you.

Beyond that, please remember that SAML specifically enables the assertion
consumer to challenge the assertion bearer to prove that the bearer is the
rightful owner of the assertion. This is provided via
<saml:SubjectConfirmation>n (see Section of SAML 1.0
cs-sstc-core-01). It is still true that the assertion consumer must trust
the assertion producer. But, the assertion consumer need not necessarily
trust the bearer to be the rightful owner of the assertion.

Now, while it is true that SAML Browser/POST profile simply uses "bearer" as
the confirmation method, future profiles can in fact call out for a
<saml:SubjectConfirmation> that specifically has a <ds:KeyInfo> as
<saml:SubjectConfirmationData>. The long and short of it is that the
assertion consumer can challenge the bearer to prove possession of the
secret key whose corresponding public key is in the signed assertion.


Jahan Moreh
Chief Security Architect

> -----Original Message-----
> From: Adam Theo [mailto:theo@theoretic.com]
> Sent: Tuesday, November 12, 2002 9:30 PM
> 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