Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Re: RESTful claims-based authorization

Expand Messages
  • Jørn Wildt
    Hi Bruno, Are you using the SSL certificate to convey claims like email etc.? As I understand SSL it will be imposible to cache anything like you normaly can
    Message 1 of 4 , Jan 3, 2010
    • 0 Attachment
      Hi Bruno,

      Are you using the SSL certificate to convey claims like email etc.? As I
      understand SSL it will be imposible to cache anything like you normaly can
      using REST - is that right? Seems like you loose something that way -
      especially if it's not encryption you are aiming for, but only trust in
      claims.

      > This being said, discovering the identity in FOAF+SSL is really where
      > this system makes use of REST: your ID is a URI (a WebID) than can be
      > dereferenced and about which things can be said using RDF/semantic web.

      Yes, using a URL as an ID seems like a good idea. As you say, you can state
      all sorts of thing at the end of the URL. As I remember it, this is quite a
      bit like what OpenID is doing, and, using some crypto stuff I do not
      understand, the server can be assured that the URL is in fact controlled by
      the client.

      > I sometimes wish there were 'WWW-Authenticate: transport' (or something
      > similar, to make handling tokens out of HTTP like SSL client-certificate
      > cleaner, and thus avoid some problems related to the TLS renegotiation
      > issue) or 'WWW-Authenticate: token' (to have clear
      > authentication-dedicated tokens, rather than cookies that are also used
      > for sessions), but they just don't exist in browser.

      Okay, so using SSL, OpenID, SAML, whatever: it seems like their is no
      standard way of transporting non-username/passsword claims after an initial
      handshake, except for using cookies.

      So the defacto standard way is quite simple: use cookies for storing
      proprietary security claims or session identifiers. Right?

      Or, if you ignore browsers, you can use "Authorization: MyVendorAuth XYZ"
      where MyVendorAuth identifies a proprietary claims-encoding method. Right?

      /Jørn

      ----- Original Message -----
      From: "Bruno Harbulot" <Bruno.Harbulot@...>
      To: <rest-discuss@yahoogroups.com>
      Sent: Wednesday, December 30, 2009 6:12 PM
      Subject: [rest-discuss] Re: RESTful claims-based authorization


      > Hello Jørn,
      >
      > You could in principle define your own headers (or try to standardise
      > some headers) to propagate SAML assertions (or similar tokens) in a
      > RESTful way. Unfortunately, that's unlikely to work in browsers.
      >
      > Even SAML's HTTP Redirect (GET) Binding is often only a one-off thing
      > that can only be used to log in (and thus get a cookie), otherwise you'd
      > have to repeat this query for all URIs you want to use (and thus change
      > the URI, since the query is part of the URI, strictly speaking).
      >
      > We've been doing some work on FOAF+SSL whereby you avoid the non-RESTful
      > authentication issue by using a TLS/SSL client-certificate for the
      > authentication (which is under the HTTP level), but for servers that
      > don't support SSL (or even the settings required for FOAF+SSL), we've
      > also had to use some SSO-like login mechanism via cookies.
      > This being said, discovering the identity in FOAF+SSL is really where
      > this system makes use of REST: your ID is a URI (a WebID) than can be
      > dereferenced and about which things can be said using RDF/semantic web.
      >
      >
      > The issue of using cookies for authentication/authorisation comes from
      > the lack of browser support (and standardisation) for other headers.
      > I sometimes wish there were 'WWW-Authenticate: transport' (or something
      > similar, to make handling tokens out of HTTP like SSL client-certificate
      > cleaner, and thus avoid some problems related to the TLS renegotiation
      > issue) or 'WWW-Authenticate: token' (to have clear
      > authentication-dedicated tokens, rather than cookies that are also used
      > for sessions), but they just don't exist in browser.
      > Would it be worth suggesting this approach to the HTTP WG? Perhaps, but
      > there's little point doing so if the major browser vendors are not on
      > board. I presume most people consider that cookies are an acceptable
      > practical solution, even if it breaks the REST principles.
      >
      >
      > Best wishes,
      >
      > Bruno.
      >
      >
      > Jørn Wildt wrote:
      >>
      >>
      >> Is there any standard RESTful way of doing claims based authorization
      >> a'la
      >> SAML and CardSpace? The authorization schemes I have seen so far usually
      >> encodes a user reference and nothing more - there's no secure way to
      >> assert
      >> claims like email=xxx@... <mailto:email%3Dxxx%40yyy.zz> or
      >> employeenumber=12345 or age-below-twenty.
      >>
      >> I guess you can use SAML "HTTP Redirect (GET) Binding", but that
      >> generates
      >> such a huge URL that it seems impractical to use (it's a base-64
      >> encoding of
      >> a zip-encoding of a SAML XML document).
      >>
      >> As I understand it a RESTful authorization scheme must be stateless, so
      >> you
      >> cannot rely on any kind of session use. This means you have to transfer
      >> all
      >> the claims on each and every request which again means a potentially big
      >> overhead.
      >>
      >> What is needed is a standard way of encoding multiple claims in a
      >> compact,
      >> secure, trusted way such that they can be transferred on each request
      >> without too much overhead (including whatever crypto stuff is needed).
      >>
      >> Maybe you could create a temporary ressource somewhere with the claims,
      >> then
      >> at least you only had to transfer the claims URL, not all the claims, and
      >> the server could then cache these claims.
      >>
      >> Any ideas or references?
      >>
      >> It even occurs to me that claims could be more RESTful than
      >> username/password since they don't require any out-of-band setup of user
      >> accounts. All that is needed is a standard for claims and then everything
      >> should work if the claims are issued by an authority that the web service
      >> trusts. No need for any human interaction - the server just sends a
      >> challenge "show me your claims (and I accept them from authority X, Y and
      >> Z)" whereafter the client sends the claims. These claims can even be
      >> obtained without human interaction if the client and the claims server
      >> trust
      >> each other.
      >>
      >> Comments?
      >>
      >> Thanks, Jørn
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
    • Jorn Wildt
      I know this is an old thread, but I just want to inform other readers that might find it through a search engine, that Microsoft, Google, and Yahoo has put
      Message 2 of 4 , Mar 2, 2010
      • 0 Attachment
        I know this is an old thread, but I just want to inform other readers that might find it through a search engine, that Microsoft, Google, and Yahoo has put together a solution called "OAuth WRAP".

        With WRAP you can present security claims using simple small security tokens called SWT.

        There's a pretty good presentation here: http://microsoftpdc.com/Sessions/SVC19 - it refers pretty much to Microsofts Azure Access Control service, but the protocols used are standardized.

        Homepage: http://wiki.oauth.net/OAuth-WRAP

        Discussion group: http://groups.google.com/group/oauth-wrap-wg

        /Jørn

        --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
        > >> Is there any standard RESTful way of doing claims based
        > >> authorization a'la SAML and CardSpace? The authorization schemes I
        > >> have seen so far usually encodes a user reference and nothing more
        > >> - there's no secure way to assert claims like email=xxx@...
        > >> <mailto:email%3Dxxx%40yyy.zz> or
        > >> employeenumber=12345 or age-below-twenty.
        > >>
        > >> I guess you can use SAML "HTTP Redirect (GET) Binding", but that
        > >> generates such a huge URL that it seems impractical to use (it's a
        > >> base-64 encoding of a zip-encoding of a SAML XML document).
        > >>
        > >> As I understand it a RESTful authorization scheme must be
        > >> stateless, so you cannot rely on any kind of session use. This
        > >> means you have to transfer all the claims on each and every request
        > >> which again means a potentially big overhead.
        > >>
        > >> What is needed is a standard way of encoding multiple claims in a
        > >> compact, secure, trusted way such that they can be transferred on
        > >> each request without too much overhead (including whatever crypto
        > >> stuff is needed).
        > >>
        > >> Maybe you could create a temporary ressource somewhere with the
        > >> claims, then at least you only had to transfer the claims URL, not
        > >> all the claims, and the server could then cache these claims.
        > >>
        > >> Any ideas or references?
        > >>
        > >> It even occurs to me that claims could be more RESTful than
        > >> username/password since they don't require any out-of-band setup of
        > >> user accounts. All that is needed is a standard for claims and then
        > >> everything should work if the claims are issued by an authority
        > >> that the web service trusts. No need for any human interaction -
        > >> the server just sends a challenge "show me your claims (and I
        > >> accept them from authority X, Y and Z)" whereafter the client sends
        > >> the claims. These claims can even be obtained without human
        > >> interaction if the client and the claims server trust each other.
        > >>
        > >> Comments?
        > >>
        > >> Thanks, Jørn
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.