In the web.xml file we have configured a listener as usual for spring context and filter for Shiro. What we are about concerned here is the way the filter is defined. Notice the name of the filter. That exact name is the name of the bean defined in the applicationContext.xml which we are going to create later. The DelegatingFilterProxy in Spring gets the name of the filter and finds a bean matching the name in the application context xml file. applicationContext.xml
Apart from hibernate related beans, notice the other three beans. In shiroFilter bean’s filterChainDefinitions list contains a list of URLS along with their authorized role names. For eg:
admin** = authcBasic, roles[ROLE_ADMIN]
says that only users having ROLE_ADMIN role can access to URLs starting with /admin. If user is not authenticated, a browser generated login dialog will be displayed (HTTP BASIC AUTHENTICATION).
We are using a custom realm, so that we can use hibernate to get user accounts from the database for authentication and authorization. A realm in Shiro is a way of accessing security data. We can use an in memory database or JDBC or any other way of data retrieval method. Since we want to use hibernate we are going to need a custom Realm. Since we have our own custom relam, we have to tell Shiro’s security manager by setting the property ‘realm’ in the securityManager bean.
MyRealm.java
Hibernate entity clases: Users.java and UserRole.java
Note If your passwords are hashed in your database then, you might want to implement your own password matcher and change credentialsMatcher to your implementation in your custom realm as follows. Notice we have defined this bean via annotations. MyMatcher.java
Now update your realm bean configuration to refer to custom password matcher: applicationContext.xml