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

[Adam Theo <theo@theoretic.com>]

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
> mark.wilcox@webct.com.