SAML and URNs
SAML
I am reading through the SAML specifications in an effort to understand Shibboleth. OpenID seems to be a competing technology to solve the single sign on(SSO) problem. OpenID is a grassroots effect, while Shibboleth is industry lead, so it will be interesting to see who wins this one. Shibboleth offers more functionality by going beyond just supporting idenity, it can also provide attributes about the user that can be used by a service for making authorization decisions. The cost of this is complexity and performance: lots of XML that has to be signed and encrypted.
One interesting thing in the SAML specs is that it states that Web proxies should not cache certain messages. Is it worth while saying this, can you really trust proxies to do what you ask them? (Byzantine faults) What are the consequences if they do cache them?
The real point of this post is this URI from SAML 2.0:
urn:oasis:names:tc:SAML:2.0:status:Success
Tried clicking on it? First it should be a http URI
Second I am concerned about the 2.0. Has success been redefined since SAML 1.0?
Now for a bit of HTTP bashing. Even toddlers know what HTTP 200, 404, 201 etc mean. But can we reuse them in other specs. Maybe if they were URIs! Why are the error codes in HTTP not URIs? Anything that can have a URI can be a resource, surely 404 deserves to have URI.
I am reading through the SAML specifications in an effort to understand Shibboleth. OpenID seems to be a competing technology to solve the single sign on(SSO) problem. OpenID is a grassroots effect, while Shibboleth is industry lead, so it will be interesting to see who wins this one. Shibboleth offers more functionality by going beyond just supporting idenity, it can also provide attributes about the user that can be used by a service for making authorization decisions. The cost of this is complexity and performance: lots of XML that has to be signed and encrypted.
One interesting thing in the SAML specs is that it states that Web proxies should not cache certain messages. Is it worth while saying this, can you really trust proxies to do what you ask them? (Byzantine faults) What are the consequences if they do cache them?
The real point of this post is this URI from SAML 2.0:
urn:oasis:names:tc:SAML:2.0:status:Success
Tried clicking on it? First it should be a http URI
Second I am concerned about the 2.0. Has success been redefined since SAML 1.0?
Now for a bit of HTTP bashing. Even toddlers know what HTTP 200, 404, 201 etc mean. But can we reuse them in other specs. Maybe if they were URIs! Why are the error codes in HTTP not URIs? Anything that can have a URI can be a resource, surely 404 deserves to have URI.
posted by Mark Mc Keown at 8:19 AM
0 Comments:
Post a Comment
<< Home