1 2 Previous Next 22 Replies Latest reply on Jun 26, 2008 6:26 AM by dlofthouse

    GSSAPI/Negotiate

    leifj

      I was asked to provide input to this forum about the uses of GSSAPI/Negotiate. The source of this was this post: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73418

      The usecases I am working with typically involve n-tier application using e2e security associations from client to backend. GSSAPI today implies Kerberos or GSI and since GSI (Grid Security Infrastructure) has a separate set of http bindings we are talking about Kerberos5 today. The origin of GSSAPI/Negotiate is MS NTML web authentication - more info here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-2.asp

      My team has compiled several implementations of the Negotiate protocol: http://devel.it.su.se/pub/jsp/polopoly.jsp?d=1047 where you will also find other use-cases and references.

      N-tier applications with GSSAPI-enabled backends is a very specific usecase: By using GSSAPI with credentials forwarding the WS is able to call the backend using the proper credentials. Example GSSAPI enabled services include datastores, filesystems (eg AFS, NFSv4) and messaging services (xmpp). Note that this only requires that the same GSSAPI mechanism is negotiable (using SPNEGO) for all services. In other words, the GSSAPI-layer in the WS application server can be mechanism-agnostic to a large degree.

      In an enterprise-environment where Kerberos is deployed (for instance using an Active Directory domain) Negotiate is a simple and easy to deploy SSO for webservices in the domain.

        • 1. Re: GSSAPI/Negotiate
          anil.saldhana
          • 2. Re: GSSAPI/Negotiate
            leifj

             

            "anil.saldhana@jboss.com" wrote:
            http://wiki.jboss.org/wiki/Wiki.jsp?page=NegotiateKerberos

            Is there any alignment here, Leif?


            Yes my work essentially is the same thing wo the dependencies on jcifs, which imo is a bit more clean. My implementation does not provide SPNEGO but this is a relatively minor detail since SPNEGO in java 1.5 should be implemented via the gss mechanism spi framework. I was in fact aware of this work but at the time the wiki page didn't include any source or material beyond a short initial description. One of my collegues implemented an initial Negotiate mech as a servlet filter which I then reworked into a Valve.

            • 3. Re: GSSAPI/Negotiate
              cdelashmutt

              Hello Leif!

              I was actually responsible for that wiki page, and I'm interested in being able to provide truly silent authentication for JBoss Application Server.

              I've actually been somewhat dissatisfied with using jCIFS for a variety of reasons, so I'd love to have a look at your stuff when I get a chance. My goal is to finish this code off with full SPNEGO support to fully integrate silent authentication for all major platforms.

              Currently there are a few problems with my code related to jCIFS and probably just my poor coding ;). My stuff currently only does NTLM, or NTLM embeded in Negotiate. For getting groups, I use RAP. These methods are really the old/archaic way of doing things, and they sometimes are unreliable on Windows 2000 and above for a variety of reasons. Ideally, I'd like to extend this module to use SPNEGO+Kerberos for authentication (shouldn't be too difficult), and PAC for group information. I'm focusing on Windows right now simply because I have more experience with that platform, but obviously I'd like this module to work for all the major platforms.

              My other goal is to make this work in a Web environment or in a fat client type environment. The server side stuff should ideally end up being the same, and it is the client side stuff (JAAS callback handlers, etc) that would be slightly different. I've seen a couple different Tomcat specific stuff to do Negotitate, but I want this to be tied more to JAAS than to Tomcat. Ideally any Tomcat stuff would just use JAAS (much in the same way that Tomcat currently does for most security stuff in JBoss AS).

              Does this make sense?

              • 4. Re: GSSAPI/Negotiate
                anil.saldhana

                Chris/Leif, I hope u can discuss further on this gss/negotiate stuff.

                On the other hand, I want to look all of these from the perspective of JSR-196 that allows me to plug security providers at the client and the server side. Look at it as a generalized JAAS infrastructure.

                Ideally, when I get some more time and tie the loose ends for the JSR-196 implementation (my current first pass needs some work done), I would be very happy to see a ClientAuthModule and a ServerAuthModule doing GSS/NEGO with the Windows infrastructure....

                I also want to highlight that we are considering to incorporate an architecture that can integrate well with the Microsoft Infocard initiative.

                • 5. Re: GSSAPI/Negotiate
                  cdelashmutt

                  I hadn't seen JSR-196 before now, but I like it for this use case especially. This is specifying something I had to hack together with ThreadLocals to work properly with JBossSX without having to change the Tomcat or JBossSX APIs. Very cool!

                  I looked at some of the high level info about InfoCard, and the initiative seems very bold in it's scope, but I'm a little wary of it's heavy reliance on Web Services. Some of that may be because of my lack a familiarity with the Web Services Security framework. My guess is that this initiative wouldn't be fully realized until MS releases Vista. However, JSR-196 should work just fine with any sort of provider, and give us a spec compliant way to pass information between the user, server, and authentication frameworks.

                  Overall, I think that this GSSAPI/Negotiate module would be an excellent canidate for inclusion with a JSR-196 framework in JBossSX.

                  • 6. Re: GSSAPI/Negotiate
                    anil.saldhana

                    Java-GSS API is part of J2SE since 1.4. Looking at it deeper, seems like the objective is the same as JSR-196 - to provide a higher level mechanism to define security services to external providers. Currently the j2se version just defines a kerberos binding, with a mention of support for extension by vendors.

                    Now to talk on similarities - GSSManager has some similar methods to AuthContextFactory (JSR-196) and the methods wrap/unwrap do the same thing as secureRequest/validateRequest (JSR-196).

                    Chris/Leif - are you using J-GSS as part of jdk1.4(and later)? I do see Leif making a comment about jdk5 gss-api spi. So my guess is that neither of you are using it currently.

                    If we are going to integrate the GSSApi/NEGO as a usecase to the generic security layer based off of jsr-196, we will have to give some thoughts on the mapping of jsr-196 framework to J-Gss api (more from the perspective of bridging).

                    • 7. Re: GSSAPI/Negotiate
                      leifj

                       

                      "anil.saldhana@jboss.com" wrote:
                      Chris/Leif - are you using J-GSS as part of jdk1.4(and later)? I do see Leif making a comment about jdk5 gss-api spi. So my guess is that neither of you are using it currently.


                      I am using the jgss that comes with jdk 1.5 - since the version in jdk 1.4 doesn't support the crypto mechs I need. My reference to jgss spi was in the context of SPNEGO. SPNEGO is a gss pseudo-mechanism that provides protected negotiation of other mechanisms.

                      • 8. Re: GSSAPI/Negotiate
                        leifj

                         

                        "anil.saldhana@jboss.com" wrote:
                        Chris/Leif - are you using J-GSS as part of jdk1.4(and later)? I do see Leif making a comment about jdk5 gss-api spi. So my guess is that neither of you are using it currently.


                        I am using the jgss that comes with jdk 1.5 - since the version in jdk 1.4 doesn't support the crypto mechs I need. My reference to jgss spi was in the context of SPNEGO. SPNEGO is a gss pseudo-mechanism that provides protected negotiation of other mechanisms.

                        • 9. Re: GSSAPI/Negotiate
                          cdelashmutt

                           

                          "anil.saldhana@jboss.com" wrote:

                          Chris/Leif - are you using J-GSS as part of jdk1.4(and later)? I do see Leif making a comment about jdk5 gss-api spi. So my guess is that neither of you are using it currently.


                          I'm not using it currently, either. My stuff uses libraries from the jCIFS project. Obviously using built in stuff is better if we can.

                          • 10. Re: GSSAPI/Negotiate
                            anil.saldhana

                            Once the JSR-196 based framework appears in HEAD in a few days, will it be possible to churn out a serverauth module to do gss/nego stuff?

                            I guess if we need a testcase, it needs to be setup seperately?

                            • 11. Re: GSSAPI/Negotiate
                              cdelashmutt

                              The past few weeks have been fairly busy with the holidays, my relocation, and other job stuff, so I haven't been able to give much attention to this.

                              I can check myself, but is the JSR-196 stuff now in HEAD and stable enough to write something on top of?

                              If so, I'll commence to try and put together the serverauth module.

                              • 12. Re: GSSAPI/Negotiate
                                anil.saldhana

                                I have the framework there. I have not integrated the containers with the JASPI (JSR-196) framework yet.

                                I am presuming that you will have much more work to do than just plain ServerAuthModule to get what you want. But atleast make the start and if you have any issues, start posting on this thread, so I can update the framework.

                                • 13. Re: GSSAPI/Negotiate
                                  cdelashmutt

                                  I'm still working on this module, but time restrictions with my day job have kept me from being able to devote signifigant time to it. Also, I've gotten a bit sidetracked trying to make sure that the module will properly fail back to NTLM if Kerberos isn't available for some reason. Getting group info reliably on a W2K and later system doesn't have a lot of good support yet in Java that I've been able to find. I'm currently focusing on using RAP via the JARAPAC library which is somewhat cumbersome to work with.

                                  I have gotten Kerberos authentication working properly, but I haven't gotten to the point of getting groups for an authenticated user. My thought thusfar is to use Microsoft's PAC extension to Kerberos to get that info, but that is about as far as I've gotten.

                                  • 14. Re: GSSAPI/Negotiate
                                    leifj

                                     

                                    "cdelashmutt" wrote:

                                    I have gotten Kerberos authentication working properly, but I haven't gotten to the point of getting groups for an authenticated user. My thought thusfar is to use Microsoft's PAC extension to Kerberos to get that info, but that is about as far as I've gotten.


                                    There have been discussions within the IETF community (on the krb-wg mailinglist) about including support for KDC-signed SAML assertions in the TGT and/or service tickets in much the same way the PAC works today. When this was discussed at the last-but-one IETF in Vancouver at the krb-wg meeting there was lots of nodding of heads.

                                    Developers should be aware that the relationship between authorization data and kerberos may well change in the near future and make allowances for that.

                                    1 2 Previous Next