Java Web Application Security - Part III: Apache Shiro Login Demo
Join the DZone community and get the full member experience.
Join For Freea couple weeks ago, i wrote a tutorial on how to implement security with spring security . the week prior, i wrote a similar tutorial for java ee 6 . this week, i'd like to show you how to implement the same features using apache shiro . as i mentioned in previous articles, i'm writing this because i told the audience at april's ujug that i would publish screencasts of the demos.
today, i've finished the third screencast showing how to implement security with apache shiro. below is the presentation (with the screencast embedded on slide 22) as well as a step-by-step tutorial.
apache shiro login tutorial
- download and run the application
- implement basic authentication
- force ssl
- implement form-based authentication
- store users in a database
- summary
download and run the application
to begin,
download the application
you'll be implementing security in. this app is a stripped-down version of the ajax login application i wrote for my article on
implementing ajax authentication using jquery, spring security and https
. you'll need java 6 and maven installed to run the app. run it using
mvn jetty:run
and open
http://localhost:8080
in your browser. you'll see it's a simple crud application for users and there's no login required to add or delete users.
implement basic authentication
the first step is to protect the list screen so people have to login to view users. to do this, you'll need to create a shiro.ini file shiro's configuration. create
src/main/resources/shiro.ini
and populate it with the contents below:
[main] [users] admin = admin, role_admin [roles] role_admin = * [urls] /app/users = authcbasic
you can see this file has four sections and is pretty simple to read and understand. for more information about what each section is for, check out shiro's configuration documentation .
next, open src/main/webapp/web-inf/web.xml and add shiro's inishirofilter:
<filter>
<filter-name>securityfilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.inishirofilter</filter-class>
<!-- no init-param means load the ini config from classpath:shiro.ini -->
</filter>
and add its filter-mapping just after the rewritefilter in the filter-mappings section (order is important!):
<filter-mapping>
<filter-name>rewritefilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>securityfilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>request</dispatcher>
<dispatcher>forward</dispatcher>
<dispatcher>include</dispatcher>
</filter-mapping>
then add shiro's core and web dependencies to your pom.xml:
<dependency>
<groupid>org.apache.shiro</groupid>
<artifactid>shiro-core</artifactid>
<version>1.1.0</version>
</dependency>
<dependency>
<groupid>org.apache.shiro</groupid>
<artifactid>shiro-web</artifactid>
<version>1.1.0</version>
</dependency>
at this point, if you restart jetty (ctrl+c and jetty:run again), you should be prompted to login when you click on the "users" tab. enter admin/admin to login. apache shiro is easier to configure than spring security out-of-the-box, mostly because it doesn't require xml.
after logging in, you can try to logout by clicking the "logout" link in the top-right corner. this calls a logoutcontroller with the following code that logs the user out.
public void logout(httpservletresponse response) throws servletexception, ioexception {
request.getsession().invalidate();
response.sendredirect(request.getcontextpath());
}
note: shiro doesn't currently have a way to logout with its api. however, it will be added in the 1.2 release .
you'll notice that clicking this link doesn't log you out, even though the session is invalidated. the only way to logout with basic authentication is to close the browser. in order to get the ability to logout, as well as to have more control over the look-and-feel of the login, you can implement form-based authentication. before you implement form-based authentication, i'd like to show you how easy it is to force ssl with apache shiro.
force ssl
apache shiro allows you to force ssl on a url by simply adding "ssl[
port
]" to a url in the [urls] section. if you don't specify the port, it will use the default port (443). i'm not sure if it allows you to switch back to http like spring security's
requires-channel
, but i don't think it does. modify the urls section of your
shiro.ini
to have the following:
[urls] /app/users = ssl[8443],authc
in order for this to work, you have to configure jetty to listen on an ssl port. add the following just after the jetty-maven-plugin's </webappconfig> element in your pom.xml:
<connectors>
<connector implementation="org.eclipse.jetty.server.nio.selectchannelconnector">
<forwarded>true</forwarded>
<port>8080</port>
</connector>
<connector implementation="org.eclipse.jetty.server.ssl.sslselectchannelconnector">
<forwarded>true</forwarded>
<port>8443</port>
<maxidletime>60000</maxidletime>
<keystore>${project.build.directory}/ssl.keystore</keystore>
<password>appfuse</password>
<keypassword>appfuse</keypassword>
</connector>
</connectors>
the keystore must be generated for jetty to start successfully, so add the keytool-maven-plugin just above the jetty-maven-plugin in pom.xml.
<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>keytool-maven-plugin</artifactid>
<version>1.0</version>
<executions>
<execution>
<phase>generate-resources</phase>
<id>clean</id>
<goals>
<goal>clean</goal>
</goals>
</execution>
<execution>
<phase>generate-resources</phase>
<id>genkey</id>
<goals>
<goal>genkey</goal>
</goals>
</execution>
</executions>
<configuration>
<keystore>${project.build.directory}/ssl.keystore</keystore>
<dname>cn=localhost</dname>
<keypass>appfuse</keypass>
<storepass>appfuse</storepass>
<alias>appfuse</alias>
<keyalg>rsa</keyalg>
</configuration>
</plugin>
now if you restart jetty, go to http://localhost:8080 and click on the "users" tab, you'll be prompted to accept the untrusted certificate and then redirected to https://localhost:8443/users after logging in.
now let's look at how to have more control over the look-and-feel of the login screen, as well as how to make logout work with form-based authentication.
implement form-based authentication
to change from basic to form-based authentication, you simply have to add a few lines to shiro.ini. first of all, since i'd rather not change the name of the input elements in login.jsp, override the default names in the [main] section:
# name of request parameter with username; if not present filter assumes 'username' authc.usernameparam = j_username # name of request parameter with password; if not present filter assumes 'password' authc.passwordparam = j_password authc.failurekeyattribute = shirologinfailure
then change the [urls] section to filter on login.jsp and use "authc" instead of "authcbasic":
[urls] # the /login.jsp is not restricted to authenticated users (otherwise no one could log in!), but # the 'authc' filter must still be specified for it so it can process that url's # login submissions. it is 'smart' enough to allow those requests through as specified by the # shiro.loginurl above. /login.jsp = authc /app/users = ssl[8443],authc
then change login.jsp so the form's action is blank (causing it to submit to itself) instead of j_security_check:
1.
<
form
action
=
""
id
=
"loginform"
method
=
"post"
>
now, restart jetty and you should be prompted to login with this jsp instead of the basic authentication dialog.
store users in a database
to store your users in a database instead of file, you'll need to add a few settings to shiro.ini to define your database and tables to use. open
src/main/resources/shiro.ini
and add the following lines under the [main] section.
jdbcrealm=org.apache.shiro.realm.jdbc.jdbcrealm #jdbcrealm.permissionslookupenabled=false # if not filled, subclasses of jdbcrealm assume "select password from users where username = ?" jdbcrealm.authenticationquery = select user_pass from users where user_name = ? # if not filled, subclasses of jdbcrealm assume "select role_name from user_roles where username = ?" jdbcrealm.userrolesquery = select role_name from users_roles where user_name = ? ds = com.mysql.jdbc.jdbc2.optional.mysqldatasource ds.servername = localhost ds.user = root ds.databasename = appfuse jdbcrealm.datasource = $ds
this configuration is similar to what i did with the java ee 6 tutorial where i'm pointing to a database other than the h2 instance that's used by the application. i believe shiro can talk to a dao like spring security, but i have yet to explore that option.
while you're at it, add the following lines to enable password encryption.
sha256matcher = org.apache.shiro.authc.credential.sha256credentialsmatcher jdbcrealm.credentialsmatcher = $sha256matcher
you'll need to install mysql for this to work. after installing it, you should be able to create an "appfuse" database using the following command:
mysql -u root -p -e 'create database appfuse'
then create the tables necessary and populate it with an 'admin' user. login using "mysql -u root -p appfuse" and execute the following sql statements:
create table users ( user_name varchar(30) not null primary key, user_pass varchar(100) not null ); create table user_roles ( user_name varchar(30) not null, role_name varchar(30) not null, primary key (user_name, role_name) ); insert into users values ('admin', '22f256eca1f336a97eef2b260773cb0d81d900c208ff26e94410d292d605fed8'); insert into user_roles values ('admin', 'role_admin');
now if you restart jetty, you should be able to login with admin/adminjdbc and view the list of users.
summary
in this tutorial, you learned how to implement authentication using apache shiro 1.1.0. i don't have a lot of experience with apache shiro, but i was able to get the basics working without too much effort. this tutorial doesn't show how to do remember me because i couldn't figure it out in 5 minutes, which means i have 5 more minutes before it fails the 10-minute test.
shiro was formerly named jsecurity and has been an apache project for less than a year. it seems to be more targeted towards non-web use, so its certainly something to look at if you're more interested in cryptography or non-web apps. i think there's a good chance this project will continue to grow and be used more as more developers learn about it. the apache brand certainly doesn't hurt.
i didn't include a slide about the limitations i found with shiro, mostly because i haven't used it much. i've used java ee and spring security for several years. the main limitation i found was the lack of documentation, but i've heard it's improving rapidly.
this marks the end of this series on implementing security in java web applications. i'll be presenting this topic at jazoon as well as the long-form version (with hacking) at überconf . hopefully i'll see you at one of those conferences.
from http://raibledesigns.com/rd/entry/java_web_application_security_part2
Opinions expressed by DZone contributors are their own.
Comments