Yes, I do still have plans to contribute this to Shiro, though the timeline is pretty murky at the moment because other tasks currently have priority.
Your particular case is (fortunately) the best-case scenario. If your users are always using IE and are logged onto the domain, the browser should always negotiate Kerberos 5, which can be handled by Java. I'm pretty sure that Chrome will also default to this, though Firefox may need some tweaking of "about:config" to convince it to use HTTP Negotiate. The general roadmap for how to handle this using Shiro is as follows: - Set up an account in Active Directory for authenticating the server. You'll need to map a service principal to that account; the principal should be of the form "HTTP/fully.qualified.domain" (if you're using DNS aliases, you may need to map the aliases as well). - Export or generate a keytab for that service account for use by Java. - Using Shiro, write a custom AuthenticationToken class that simply wraps a byte[]. The details of the authentication will be taken care of JGSS - all you need are adapters to interface with Shiro. - Write a custom Realm that handles the type you defined in the previous step. The relevant parts of JGSS are javax.security.auth.login.LoginContext and org.ietf.jgss.*. I'd highly suggest going through the source code for the existing SPNEGO project (http://spnego.sourceforge.net/) as well as the Oracle JAAS tutorials ( http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/lab/part1.html and http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/lab/part2.html). The SPNEGO examples are the ones that you should focus on. - Write a Shiro filter that parses the headers appropriately and generates the AuthenticationToken type you defined previously from the base64-encoded contents of the Authorization header. - Configure JAAS for your servlet container. It should look similar to the "server" block in the first JAAS tutorial linked above. Hopefully I'll be able to get the code for this cleaned up enough to be contributed before you try to re-implement the entire stack, but in case that doesn't happen, I hope the above is useful in guiding your efforts. If you run into any issues or have any questions, please feel free to send another reply to this thread. On Mon, Sep 12, 2011 at 2:27 AM, Bengt Rodehav - [email protected] wrote: > Thanks for your reply, > > Obviously you're much more competent in this area than me. I haven't done > this myself so I don't really know what it takes. In my case, the server > side OS is Windows 2003/2008 server. The browser is IE 8/9. The client OS is > Windows XP or Windows 7. The users are always logged into an Active > Directory domain. > > I don't know enough about Kerberos to know what version is required. I did > have HTTP Negotiate in mind (although I don't know exactly how it works). It > would be really nice if the modern versions of Chrome and Firefox could also > be supported although IE has the highest priority. > > I think it would be great if a project like Shiro could provide this > functionality. I really think it would be a killer app. I'm not sure how > much of a "security wiz" I have to be in order to roll my own (perhaps using > pointers from you). Would you consider my scenario as relatively easy or > somewhat complex? > > Are you still planning to contribute this to Shiro? If so, do you have a > rough idea of when this might be possible? > > /Bengt > > > 2011/9/12 <[email protected]> > > Having worked on something similar for an internal project, I can tell you >> that properly handling the entire spectrum of Microsoft authentication >> protocols is extremely difficult, if not outright impossible. Certain parts >> are easy - for example, if the only case you need to support is Kerberos 5 >> via HTTP Negotiate, it's relatively straightforward to write Shiro-based >> code to handle that scenario using JGSS. If you need to handled mixed >> deployments (e.g. domain versus non-domain, different browsers, different >> versions of browsers, different versions of Windows, even the >> presence/absence of other Microsoft software) though, you run into all kinds >> of issues because nearly every configuration seems to do something >> different. >> >> I do have some code that I've been planning to contribute back to the >> project, but in its current state, it is not sufficiently robust (i.e. >> doesn't properly handle enough of the cases) and also relies on other >> internal code that cannot be redistributed. However, I can certainly provide >> pointers on how to handle certain situations if you'd find that to be >> useful. >> >> >> On Sun, Sep 11, 2011 at 5:00 PM, Bengt Rodehav - [email protected] wrote: >> >>> Hello, >>> >>> I need to find a way to get the currently logged in Active Directory user >>> (on the server side) in a web application. This is commonly done in the >>> Microsoft World with IIS/SharePoint/.NET technology stack. I've used java >>> based software (Spring Security / Acegi) that enables authentication against >>> Active Directory (like I believe Shiro does). But this still means that the >>> user has to fill in the user and password again and explicitly login >>> although s/he is already authenticated in AD. >>> >>> I think it is necessary for us to have a "standard" solution to this in >>> the java world. I was hoping that Shiro could take on this challenge. I read >>> about a similiar request on Shiro's mailing list but I haven't seen it >>> resulting in anything ( >>> http://shiro-user.582556.n2.nabble.com/SSO-with-a-Windows-domain-td6236647.html >>> ). >>> >>> Does anyone know if any work is being done in this area? >>> >>> /Bengt >>> >> >> >
