4 Replies Latest reply: Jul 17, 2014 3:49 PM by Ricardo Av-Oracle RSS

    Windows SSO and integration servlet

    NickBannister

      Hi,

       

      I am looking into trying to implement a Single Sign On ability for an integration for AutoVue we have. I would like to be able to get the windows username (remote user) from the request/session and use this to log into the DMS.

      I have tried the built in JAAS which works but asks you to enter the username and password which isn't what i am after.

      I have implemented WAFFLE and when a put the test .jsp under the servlet it works and picks up my domain username correctly.

      Example: http://server:8080/TestServlet/index.jsp

      Usual URL to connect to servlet would be: http://server:8080/TestServlet/servlet/TestServlet.

      However when i debug the application the username being picked up seems to be the account i assume AutoVue as a service is running as.

      I have put the WAFFLE plug in under the VueServlet and this works as well here when using the test .jsp page.

      The API we use to integrate into the DMS allows to impersonate and i want to pick this up automatically. I was hoping the VueServlet would pass any header information etc onto the integration servlet but i don't think it does.

       

      Is this possible?

       

      Nick

        • 1. Re: Windows SSO and integration servlet
          NickBannister

          All,

           

          In addition check this URL: http://code.dblock.org/single-sign-on-tomcat-negotiate-authenticator-kerberos-ntlm-w-waffle

          This allows you to plug-in an authenticator that authenticates automatically for you and sets the remoteUser for java requests. Its pretty good.

          When i put this into the VueServlet it works and i put a test.jsp file under it to demonstrate the authentication works.

          the same applies to the DMS servlet!

          However the VueServlet seems to make its own new request from VueServlet to DMSServlet to the remoteUser is the username of the windows service the application server is running as.

           

          Note: All i want is the windows username of the person using AutoVue. Passing a username via the applet is not very good and i can use the built in JAAS authentication which is OK but we don't want to have the user inputting their username and password everytime they open their browser.

           

          It seems to me that VueServlet should pass the remoteUser value in some way to the DMS servlet but it doesn't so even if you have your own authentication mechanism the VueServlet doesn't let the DMS servlet know any information about the original request to the new request.

           

          I really need some help with this. How are you supposed to log into any DMS unless you pass credentials via the applet which is a security risk in itself because users can change the HTML code?

           

          Nick

          • 2. Re: Windows SSO and integration servlet
            Ricardo Av-Oracle

            The behaviour you are describing is the expected one, it is the server that is talking to the DMSServlet, so it will be the account's credentials that will be forwarded is there is nothing else you do

            The assumption that the VueServlet should pass the credential of the logged in user is unfortunately incorrect, it only tunnels requests from applet to server

            There is an authentication mechanism that is part of the AutoVue deployment, there is no other way to pass credentials but that one

            if you need automatic sign-in, on the applet side, you will need to have an authenticator in the applet

            If you have a SSO solution, ie the VueServlet and the DMSServlet using the same security realm and authentication solution you can rely on the automatic signin build in the browser ie the page from the browser will authenticate, the connections from the applet to the server will have a security token (usually a cookie) and that can be used to automatically sign you in at the DMSServlet side

             

            But essentially, without entering a user name and password or writing a module that will grab the WINDOWS credentials (which can only be securely done if you have NTLM) there is no work around.

            Security serves a purpose, and in this particular case, you are trying to bypass it.

            • 3. Re: Windows SSO and integration servlet
              NickBannister

              Ricardo,

               

              If i was to look at creating our own authenticator then how would this be passed back to the DMS servlet? All requests from the VueServlet take the identity of the windows service running the AutoVue service.

              The applet and VueServlet is step 1 and once you are passed this and the person is authenticated it seems reasonable the DMS servlet would want to know who this person is to prevent passing sensitive data via the applet.

              If the JAAS built into AutoVue is used then does this get passed back to the DMS servlet via the authentication section for each request made to the servlet?

               

              Passing all cookie data back is handy but these cookies are bound to the client they came from a lot of the time and will not work from the DMS servlet (as this is seen as a different client)

               

              Nick

              • 4. Re: Windows SSO and integration servlet
                Ricardo Av-Oracle

                Hello,

                I will ansewer item per item, so that we do not get confused

                >>If i was to look at creating our own authenticator then how would this be passed back to the DMS servlet?

                You ususually send information as cookies

                >> All requests from the VueServlet take the identity of the windows service running the AutoVue service.

                Not by default, unless you are using automatic sigin (a windows feature), that is never the case.

                OOB JAVA will not do it (only the plugin has support for it, and the default NTLM implementation of JAVA), there is probably a mistake in you setup, autovue server will NOT send any auth or identity token

                Simply because we need to handle HTTP 401

                >> The applet and VueServlet is step 1 and once you are passed this and the person is authenticated it seems reasonable the DMS servlet would want to know who this person is to prevent passing sensitive data via the applet.

                Yes, and what you are describing is a SSO solution, I would strongly recommend you look into an existing implementation

                Basically, if you are web based, that means you can use a 3rd party tool (or attach the auth cookie to the applet html page)

                If you are stand alone (DD), then you have very little option (none?).  getting credential from the system requires specific code, and then you still need to propagate credential, without something like cookies, that is simply not feasible as you will defintively not get username/pwd.

                >> If the JAAS built into AutoVue is used then does this get passed back to the DMS servlet via the authentication section for each request made to the servlet?

                The sample JAAS authenticator is solely used for server side authentication, if you need something else, it needs to be coded

                Basically, you are using LDAP and Kerberos, for SSO you will need to have an identity forwarding mechanism tied to your integration (a kerberos ticket), the authenticator on the client would need to implement one, the forward to the client then the client authenticator will need to query for username/password (or get a security context token from the process, can only be done on native code) and set the kerberos tickets (for identity fwding) as part of the query (a cookie), then the vuelink will need to process the ticket (validate the validity of the ticket with kerberos)

                >> Passing all cookie data back is handy but these cookies are bound to the client they came from a lot of the time and will not work from the DMS servlet (as this is seen as a different client)

                This is a implementation specific details, and only tied to how your implementation is done

                Other (a vast majority of them) will rely on this mechanism, but then again, that means you have SSO