Title: Message
Are
the minutes configurable?
-----Original Message-----
From: John Herendeen
[mailto:]
Sent: Wednesday, November 13,
2002 7:28 AM
To: 'Adam Theo'; Mark Wilcox
Cc:
Subject: RE: [saml-dev] Introduction
& Question about the "heaviness" of S AML
Adam,
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:]
Sent: Wednesday, November 13, 2002 12:30 AM
To: Mark Wilcox
Cc:
Subject: Re: [saml-dev]
Introduction & Question about the "heaviness" of
SAML
UPDATE:
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
> .
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
