Because most of these datasources usually contain Subject (a.k.a. User) information such as usernames and passwords, a Realm can act as a pluggable authentication module in a PAM configuration. This allows a Realm to perform both authentication and authorization duties for a single datasource, which caters to the large majority of applications. If for some reason you don't want your Realm implementation to perform authentication duties, you should override the {@link #supports(org.apache.shiro.authc.AuthenticationToken)} method to alwaysreturn false.
Because every application is different, security data such as users and roles can be represented in any number of ways. Shiro tries to maintain a non-intrusive development philosophy whenever possible - it does not require you to implement or extend any User, Group or Role interfaces or classes.
Instead, Shiro allows applications to implement this interface to access environment-specific datasources and data model objects. The implementation can then be plugged in to the application's Shiro configuration. This modular technique abstracts away any environment/modeling details and allows Shiro to be deployed in practically any application environment.
Most users will not implement the Realm interface directly, but will extend one of the subclasses, {@link org.apache.shiro.realm.AuthenticatingRealm AuthenticatingRealm} or {@link org.apache.shiro.realm.AuthorizingRealm}, greatly reducing the effort requird to implement a Realm from scratch.
@author Les Hazlewood @author Jeremy Haile @see org.apache.shiro.realm.CachingRealm CachingRealm @see org.apache.shiro.realm.AuthenticatingRealm AuthenticatingRealm @see org.apache.shiro.realm.AuthorizingRealm AuthorizingRealm @see org.apache.shiro.authc.pam.ModularRealmAuthenticator ModularRealmAuthenticator @since 0.1 | |
| |