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

Again authentication

Expand Messages
  • Sebastian Stein
    Hi, I know it is a repeating topic how to correctly authenticate a client to a REST interface. Please first note, if I talk about client I do not mean browser,
    Message 1 of 10 , Aug 2, 2006
    • 0 Attachment
      Hi,


      I know it is a repeating topic how to correctly authenticate a client to a
      REST interface. Please first note, if I talk about client I do not mean
      browser, but instead another application calling the REST interface by http.

      To make the discussion not too abstract a small example. Consider a server
      providing some kind of document repository. Each user can download documents
      (GET) or upload new documents (POST). To download a document it is necessary
      to check if the user has permissions to the document. Getting a document
      should look like this:

      HTTP GET to http://../document/123

      Now, from what I have read cookies should be no option and I agree on that.
      Another idea is that there is a special login interface, which returns a
      TOKEN for further requests. In such a case the above request would change to
      something like:

      HTTP GET to http://../document/123/TOKEN

      The disadvantage is that now the URL can not be bookmarked or exchanged
      among users anymore, because the TOKEN will be invalid for another user.

      Another often cited method is to use HTTP auth (basic or digest). But this
      is no option, if access rights are not handled by the application server but
      inside the application.

      So the perfect solution would be that the client sends each time
      username/password along with the http request, but without adding this to
      the URL. Can this be done, let's say can I just add some individual HTTP
      headers or is there a better way to do it?


      Sebastian
    • Miguel Covas O'Ryan
      Hi Sebastian, We have a (very) little experience in providing web services as a finantial institution. We provide services to other financial institutions. We
      Message 2 of 10 , Aug 2, 2006
      • 0 Attachment
        Hi Sebastian,

        We have a (very) little experience in providing web services as a
        finantial institution. We provide services to
        other financial institutions. We have set up a quite RESTful
        interface to POST orders to buy/sell mutual funds.
        They can GET a list of orders or a particular order with its current
        status.

        Of course we have to authenticate the remote user (or client
        application) to ascertain its access rights.

        Well, we use basic authentication in which they set up a proper HTTP
        Header from which we retrieve a user/password
        pair. This is not perfect of course, but it works. We are using
        private networks (VPN over Internet, leased lines, ISDN, etc.)
        but the underlying is the same. We use https and Internet in some
        cases. The fact is that we have an agreement with
        our institutional customers (On the other hand they have been using
        plain telnet applications with us for years, again
        over private networks...)

        They seem to be happy with the solution. It seems that they were able
        to start using the service in weeks.

        Now, some of them use perl scripts, others use java programs. In both
        cases they can easily set up
        headers. The following java code can be used to set up basic
        authentication headers (avoiding Authenticator object)

        String credentials = username + ":" + passwd ;
        String encoded = new sun.misc.BASE64Encoder().encode
        (credentials.getBytes());

        URL webService = new URL(url); // url is http://someservice....
        URLConnection conn0 = webService.openConnection() ;
        conn0.setRequestProperty("Authorization", "Basic " + encoded);

        HttpURLConnection conn = (HttpURLConnection) conn0 ;
        conn.connect();

        Of course the hard work is on the part of the service. We have to
        retrieve the user/password, return a 401 response
        if there is no pair, return a 404 if the resource is not there (or if
        they have no access rights), 403 if the URL is not
        accesible, 200 if we send some resource representation, a 201 if the
        POST of an order is successful, etc.

        We can discuss about opaqueness or transparency of the URL, adequacy
        of the representation of resources,
        etc. but this is not the point. The fact is that we have a dozen of
        finantial institutions using this service, this
        authorization schema and that they do not complain...

        I hope that our little experience gives you some hints about how to
        approach your solution

        Regards,

        Miguel Covas


        El 02/08/2006, a las 17:38, Sebastian Stein escribió:

        > Hi,
        >
        >
        > I know it is a repeating topic how to correctly authenticate a
        > client to a
        > REST interface. Please first note, if I talk about client I do not
        > mean
        > browser, but instead another application calling the REST interface
        > by http.
        >
        > To make the discussion not too abstract a small example. Consider a
        > server
        > providing some kind of document repository. Each user can download
        > documents
        > (GET) or upload new documents (POST). To download a document it is
        > necessary
        > to check if the user has permissions to the document. Getting a
        > document
        > should look like this:
        >
        > HTTP GET to http://../document/123
        >
        > Now, from what I have read cookies should be no option and I agree
        > on that.
        > Another idea is that there is a special login interface, which
        > returns a
        > TOKEN for further requests. In such a case the above request would
        > change to
        > something like:
        >
        > HTTP GET to http://../document/123/TOKEN
        >
        > The disadvantage is that now the URL can not be bookmarked or
        > exchanged
        > among users anymore, because the TOKEN will be invalid for another
        > user.
        >
        > Another often cited method is to use HTTP auth (basic or digest).
        > But this
        > is no option, if access rights are not handled by the application
        > server but
        > inside the application.
        >
        > So the perfect solution would be that the client sends each time
        > username/password along with the http request, but without adding
        > this to
        > the URL. Can this be done, let's say can I just add some individual
        > HTTP
        > headers or is there a better way to do it?
        >
        >
        > Sebastian
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >



        CAMBIO de DIRECCIONES de CORREO-E
        Rogamos actualice su agenda de direcciones de correo electrónico. Todas las
        direcciones de correo del dominio "@..." cambian a "@..."

        E-MAIL ADDRESSES are CHANGING
        Be advised that all the e-mail addresses from the domain "@..."
        are changing to "@...".Please update your e-mail addresses.

        AVISO LEGAL
        Este mensaje de correo electrónico y sus documentos adjuntos están dirigidos
        exclusivamente a los destinatarios especificados. Puede contener información
        confidencial o legalmente protegida. No hay renuncia a la confidencialidad o
        privilegio por cualquier transmisión errónea. Si usted no es el destinatario
        indicado, le rogamos que lo elimine y se lo comunique al remitente. No debe,
        directa o indirectamente, usar, revelar, distribuir, imprimir o copiar
        ninguna de las partes de este mensaje. Si siendo destinatario de este
        mensaje no consintiera el uso de correo electrónico, rogamos nos lo
        comunique inmediatamente.
        RBCDexia Investor Services E,S.A. y sus filiales no serán responsables de las
        opiniones o informaciones incluidas en este mensaje salvo cuando el remitente esté
        autorizado para establecer que dichas opiniones proceden de RBCDexia Investor
        Services ,S.A. y sus filiales.

        DISCLAIMER
        Addressee/s identified herein. It may contain confidential or legally
        privileged information. No confidentiality privilege is waived or lost
        by any mistransmission. If you are not the intended recipient, please
        immediately delete it and notify the sender. You must not, directly or
        indirectly, disclose, distribute, print, or copy any part of this message.
        If you are the addressee of this message and do not consent to the use of
        e-mail, please communicate it to us immediately. RBCDexia Investor Services
        S.A. and its subsidiaries are not responsible for the opinions or information
        included in this message except when the sender is authorised to state them to
        be the views of RBCDexia Investor Services, S.A. and its subsidiaries.
      • Sebastian Stein
        ... Thanks for this lengthy description of your experience. I think it is the way I intended to go. I will first again check if HTTP auth might work, but if it
        Message 3 of 10 , Aug 2, 2006
        • 0 Attachment
          Miguel Covas O'Ryan <miguel.covas@...> [060802 21:41]:
          > We have a (very) little experience in providing web services as a
          > finantial institution. We provide services to
          > other financial institutions. We have set up a quite RESTful
          > interface to POST orders to buy/sell mutual funds.
          > They can GET a list of orders or a particular order with its current
          > status.
          >
          > ...

          Thanks for this lengthy description of your experience. I think it is the
          way I intended to go. I will first again check if HTTP auth might work, but
          if it gets too complicated, I will do it as you suggested!

          Many thanks,


          Sebastian
        • Sebastian Stein
          ... I think it is not the problem to generate HTTP auth, but to handle it. But I might be wrong. On the server side I have a Tomcat handling the requests in a
          Message 4 of 10 , Aug 2, 2006
          • 0 Attachment
            Michal Migurski <mike@...> [060802 21:41]:
            > >Another often cited method is to use HTTP auth (basic or digest).
            > >But this
            > >is no option, if access rights are not handled by the application
            > >server but
            > >inside the application.
            >
            > Can you explain? I've found it pretty easy to generate the same
            > authentication headers from application code and webserver
            > configurations. I've done this in PHP, Python, and CGI without too
            > much difficulty. Seems like a no-brainer choice.

            I think it is not the problem to generate HTTP auth, but to handle it. But I
            might be wrong. On the server side I have a Tomcat handling the requests in
            a servlet derived from HttpServlet. There I have a HttpServletRequest object
            representing the HTTP request. My understanding so far was that HTTP auth is
            handled before I get the chance to react upon it in my servlet. I thought
            that the servlet container (Tomcat) handles HTTP auth before it calls my
            servlet.

            Sebastian
          • Walden Mathews
            Tomcat gives several options for implementing and patching in your own notion of realm . Check the tomcat docs. Should be no problem. ... I ... in ...
            Message 5 of 10 , Aug 2, 2006
            • 0 Attachment
              Tomcat gives several options for implementing and patching in your
              own notion of "realm". Check the tomcat docs. Should be no problem.
              :
              : I think it is not the problem to generate HTTP auth, but to handle it. But
              I
              : might be wrong. On the server side I have a Tomcat handling the requests
              in
              : a servlet derived from HttpServlet. There I have a HttpServletRequest
              object
              : representing the HTTP request. My understanding so far was that HTTP auth
              is
              : handled before I get the chance to react upon it in my servlet. I thought
              : that the servlet container (Tomcat) handles HTTP auth before it calls my
              : servlet.
              :
              : Sebastian
              :
              :
              : __________ NOD32 1.1689 (20060802) Information __________
              :
              : This message was checked by NOD32 antivirus system.
              : http://www.eset.com
              :
              :
            • John Panzer
              ... I believe it can be configured either way, and potentially differently depending on the URL path. Our application handles all authentication inside Tomcat
              Message 6 of 10 , Aug 2, 2006
              • 0 Attachment
                Sebastian Stein wrote on 8/2/2006, 12:54 PM:

                > Michal Migurski <mike@...> [060802 21:41]:
                > > >Another often cited method is to use HTTP auth (basic or digest).
                > > >But this
                > > >is no option, if access rights are not handled by the application
                > > >server but
                > > >inside the application.
                > >
                > > Can you explain? I've found it pretty easy to generate the same
                > > authentication headers from application code and webserver
                > > configurations. I've done this in PHP, Python, and CGI without too
                > > much difficulty. Seems like a no-brainer choice.
                >
                > I think it is not the problem to generate HTTP auth, but to handle it.
                > But I
                > might be wrong. On the server side I have a Tomcat handling the
                > requests in
                > a servlet derived from HttpServlet. There I have a HttpServletRequest
                > object
                > representing the HTTP request. My understanding so far was that HTTP
                > auth is
                > handled before I get the chance to react upon it in my servlet. I thought
                > that the servlet container (Tomcat) handles HTTP auth before it calls my
                > servlet.

                I believe it can be configured either way, and potentially differently
                depending on the URL path. Our application handles all authentication
                inside Tomcat except for certain paths, for example.

                John
              • Miguel Covas O'Ryan
                ... Perhaps the discussion is going off topic, but anyway, as far as I know you can always retrieve the user / password even the Tomcat is handling the
                Message 7 of 10 , Aug 2, 2006
                • 0 Attachment
                  El 02/08/2006, a las 21:54, Sebastian Stein escribió:
                  >
                  > I think it is not the problem to generate HTTP auth, but to handle
                  > it. But I
                  > might be wrong. On the server side I have a Tomcat handling the
                  > requests in
                  > a servlet derived from HttpServlet. There I have a
                  > HttpServletRequest object
                  > representing the HTTP request. My understanding so far was that
                  > HTTP auth is
                  > handled before I get the chance to react upon it in my servlet. I
                  > thought
                  > that the servlet container (Tomcat) handles HTTP auth before it
                  > calls my
                  > servlet.
                  >
                  > Sebastian

                  Perhaps the discussion is going off topic, but anyway, as far as I know
                  you can always retrieve the user / password even the Tomcat is
                  handling the headers.
                  You can either configure Tomcat to validate the user against, say, a
                  LDAP directory, then
                  if it passes the filter you can still retrieve the user and then
                  evaluate her rights based upon
                  your application or you can configure Tomcat to skip filtering that
                  particular URL. Then
                  again, you retrieve the user / password pair and validate it
                  yourself. As a matter of fact
                  we use the last approach since we use the LDAP directory to store the
                  access rights of
                  the Web Service users (in the form of group membership).

                  If you are interested I can give some hints about how we have
                  configured Tomcat
                  (out of this discussion if you don't mind)

                  CAMBIO de DIRECCIONES de CORREO-E
                  Rogamos actualice su agenda de direcciones de correo electrónico. Todas las
                  direcciones de correo del dominio "@..." cambian a "@..."

                  E-MAIL ADDRESSES are CHANGING
                  Be advised that all the e-mail addresses from the domain "@..."
                  are changing to "@...".Please update your e-mail addresses.

                  AVISO LEGAL
                  Este mensaje de correo electrónico y sus documentos adjuntos están dirigidos
                  exclusivamente a los destinatarios especificados. Puede contener información
                  confidencial o legalmente protegida. No hay renuncia a la confidencialidad o
                  privilegio por cualquier transmisión errónea. Si usted no es el destinatario
                  indicado, le rogamos que lo elimine y se lo comunique al remitente. No debe,
                  directa o indirectamente, usar, revelar, distribuir, imprimir o copiar
                  ninguna de las partes de este mensaje. Si siendo destinatario de este
                  mensaje no consintiera el uso de correo electrónico, rogamos nos lo
                  comunique inmediatamente.
                  RBCDexia Investor Services E,S.A. y sus filiales no serán responsables de las
                  opiniones o informaciones incluidas en este mensaje salvo cuando el remitente esté
                  autorizado para establecer que dichas opiniones proceden de RBCDexia Investor
                  Services ,S.A. y sus filiales.

                  DISCLAIMER
                  Addressee/s identified herein. It may contain confidential or legally
                  privileged information. No confidentiality privilege is waived or lost
                  by any mistransmission. If you are not the intended recipient, please
                  immediately delete it and notify the sender. You must not, directly or
                  indirectly, disclose, distribute, print, or copy any part of this message.
                  If you are the addressee of this message and do not consent to the use of
                  e-mail, please communicate it to us immediately. RBCDexia Investor Services
                  S.A. and its subsidiaries are not responsible for the opinions or information
                  included in this message except when the sender is authorised to state them to
                  be the views of RBCDexia Investor Services, S.A. and its subsidiaries.
                • Justin T. Sampson
                  ... HTTP Basic auth is definitely the way to go. If your framework doesn t help you, in the worst case you can just read and parse the Authorization header
                  Message 8 of 10 , Aug 2, 2006
                  • 0 Attachment
                    On 8/2/06, Sebastian Stein <seb_stein@...> wrote:

                    > Another often cited method is to use HTTP auth (basic or
                    > digest). But this is no option, if access rights are not handled
                    > by the application server but inside the application.

                    HTTP Basic auth is definitely the way to go. If your framework
                    doesn't help you, in the worst case you can just read and parse
                    the Authorization header yourself -- I did that myself recently
                    for a Java-based Web service. It's really a very simple protocol.

                    Cheers,
                    Justin
                  • Dave Pawson
                    ... Any reason why not PUT? ... We ve implemented just that using C# and Java restlets. Gives normal client login. ... We ve done it as part of the application
                    Message 9 of 10 , Aug 2, 2006
                    • 0 Attachment
                      > I know it is a repeating topic how to correctly authenticate a client to a
                      > REST interface. Please first note, if I talk about client I do not mean
                      > browser, but instead another application calling the REST interface by http.
                      >
                      > To make the discussion not too abstract a small example. Consider a server
                      > providing some kind of document repository. Each user can download documents
                      > (GET) or upload new documents (POST).
                      Any reason why not PUT?




                      > Another often cited method is to use HTTP auth (basic or digest). But this
                      > is no option, if access rights are not handled by the application server but
                      > inside the application.

                      We've implemented just that using C# and Java restlets.
                      Gives normal client login.


                      >
                      > So the perfect solution would be that the client sends each time
                      > username/password along with the http request, but without adding this to
                      > the URL. Can this be done, let's say can I just add some individual HTTP
                      > headers or is there a better way to do it?

                      We've done it as part of the application responding to the GET or PUT.


                      HTH

                      --
                      Dave Pawson
                      XSLT XSL-FO FAQ.
                      http://www.dpawson.co.uk
                    • Jon Hanna
                      ... HTTP Basic offers zero security unless encryption is coming from somewhere else (SSL). HTTP Digest is the way to go if you aren t going over a secure
                      Message 10 of 10 , Aug 3, 2006
                      • 0 Attachment
                        Justin T. Sampson wrote:

                        > On 8/2/06, Sebastian Stein <seb_stein@...> wrote:
                        >
                        >
                        >> Another often cited method is to use HTTP auth (basic or
                        >> digest). But this is no option, if access rights are not handled
                        >> by the application server but inside the application.
                        >
                        >
                        >
                        > HTTP Basic auth is definitely the way to go.


                        HTTP Basic offers zero security unless encryption is coming from
                        somewhere else (SSL). HTTP Digest is the way to go if you aren't going
                        over a secure connection.
                      Your message has been successfully submitted and would be delivered to recipients shortly.