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

Re: RESTful claims-based authorization

Expand Messages
  • Bruno Harbulot
    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
    Message 1 of 4 , Dec 30, 2009
    • 0 Attachment
      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
    • 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 2 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 3 of 4 , Mar 2 4:30 AM
        • 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.