As it stands, Lift only has its proto* traits for user management, and that system has its limitations and you will ultimately end up replacing it in any non-trivial application as your needs change and you need to grow. Whilst this is what those traits are designed for (quick start, short haul), you typically end up rolling your own system for users etc when using Lift, and this can often be somewhat cumbersome or not particularly easy to do well. As this whole user management piece is so often requested, I figured that i’d write a plugin library for Lift.
Apache Shiro is a Java security framework (formally known as JSecurity) and it comes with a fairly abstract set of classes for building systems that have the familiar users, roles and permissions setup. Pretty much most applications these days have some notion of users, customers or some other subject that you care about and might want to conduct access control around. This is exactly what Shiro is designed for, and it ships with out of the box inter-operation with ActiveDirectory and other such repositories commonly found in the enterprise space for managing user data.
Part of the reason that other security frameworks never really took to Lift (or vice-versa) is that Lift has its own mech for managing resource ACLs and it never made sense to separate that into a different servlet filter and somehow munge that together: its not 1990. Fortunately Shiro was fairly easy to integrate with Lift in such a way that it allows you to simply augment your existing SiteMap setup, template markup and even dispatch resources. Currently this integration project is in early stages, and you can find the source code here: github.com/timperrett/lift-shiro
Example
Here’s a quick walkthrough of the various ways you can use the integration within your project. Firstly, lets assume you only want to display a section of content to authenticated users:
<lift:has_role name="admin">
<p>This content is only available for admins</p>
</lift:has_role>
There are a range of authentication snippets that allow you to define who sees what within your templates, checkout the documentation for more on that. Nextup, what if you want to block access to an page entirely if the user is not authenticated? Just add the following to your SiteMap:
...
Menu("Home") / "index" >> RequireAuthentication
...
By default RequireAuthentication will redirect unauthenticated users back to the URL defined in Shiro.loginURL. Likewise, you can specify whole resources to require a particular role or permission:
...
Menu("Role Test") / "restricted" >> RequireAuthentication >> HasRole("admin")
...
Clearly the SiteMap functionality is implemented as LocParam, so you can implement them within your own Loc types, or simply use them declaratively within the regular SiteMap usage.
This whole integration project wraps the Shiro types, so you only need to configure shiro.ini in the root of your classpath and enter the appropriate realm information as per the regular Shiro documentation, then away you go: password files… active directory… whatever you want.
As above, this project is still early stage, but it does indeed work. I’m currently looking for feedback, so if you have some thoughts or things that would be cool to see, then please checkout the project on Github and fork away.
Interesting. I can see that REST guards are on your to do list but have you in the mean time tried it yet? I am both new to Scala and Lift and I need to authenticate REST resource access but I have a hard time figuring out how to do it properly. I am chasing bits & pieces to understand how Lift authentication and authorization works and the REST API seems least documented in this respect. BTW looking forward to read your book when I receive it, hope it covers it well.
Well the rest guards are just that – guards. Nothing stopping you using them today. There is an issue in that you can’t control the non-matching response so its either X or a 404, which is more than likely not suitable for a production REST service. In any case, the book covers some of the HTTP auth stuff, but not how to generally secure your REST services… thats a solved problem (OAuth etc).
Great stuff, this makes setting up a flexible security framework in Lift really easy
I’ve setup an Active Directory realm which is working but I have a couple of questions:
1. I currently have to use domain\username or username@domain in order for the authentication to work, do you know of a way to just have the user specify their username without the domain prefix or suffix?
2. Have you ever got windows SSO (Windows Integrated Security) to work with this? We will be running our Lift app on a non-IIS webserver, but are within a windows domain. Would be great if the users within our domain could login without having to specify their username and password again.
Thanks for any help/advice
Jeff,
I don’t know about the windows SSO… thats outside of my scope quite frankly
About point 1: you could probably do some munging within a custom realm implementation to do this, but I actually also roll with the domain\user combo as its what my users are used to from MS exchange OWA etc.
There may be ways to configure both of these, but you’re better of on the Shiro list – I just wrote the integration
Ok just I figured out the answer to my first question….
I set the principalSuffix = @domain