Jason,
In our application, we have a similar issue in concept. Our system is
multi-tenant, so each user account is associated with a specific tenant.
Different tenants may have users with the same username.
Solving this should not require you to use Shiro 1.2; I believe everything
you need is present in 1.1. For our purposes, implementing this revolves
around creating 3 classes, all derived from various Shiro classes:
1. Subclass UsernamePasswordToken. Ours can be thought of as
TenantUsernamePasswordToken, where the tenant ID is an additional property,
beyond the username/password held by the base class.
public class TenantUsernamePasswordToken extends UsernamePasswordToken {
private long tenantId;
public long getTenantId() { return tenantId; }
public void setTenantId(long tenantId) { this.tenantId = tenantId; }
}
2. Subclass *AuthenticatingFilter and override createToken(ServletRequest,
ServletResponse). In our system, we subclassed BasicHttpAuthenticationFilter
because we're using the filter to protect REST endpoints rather than a web
application. You may be using FormAuthenticationFilter, or some other flavor
of AuthenticatingFilter, instead. Either way, you need a subclass that
creates your new token type (by default, the various AuthenticationFilter
subclasses that exist in Shiro today all create UsernamePasswordTokens)
3. Implement your Realm. The approach we followed was to extend from
AuthorizingRealm. In our Realm subclass (we'll call it TenantUserRealm), we
have a constructor like this:
public TenantUserRealm() {
setAuthenticationTokenClass(TenantUsernamePasswordToken.class);
}
This way, our Realm is only called for tokens with our specific token type
which encapsulates the tenant ID as well as the username/password. To
complete your Realm, you implement the following two methods:
- protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
authenticationToken): This method can always cast the provided
AuthenticationToken to TenantUsernamePasswordToken--Shiro's internals handle
ensuring the token is an instance of the Realm's supported
AuthenticationToken class before calling it. Inside that method, you then
have the tenant ID (or, in your case, the domain) available in addition to
the user's credentials, thereby allowing you to authenticate the user
correctly.
- protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
principals): This method returns an AuthorizationInfo which determines what
the user identified by the provided principals (which will be whatever
principals were in the PrincipalCollection you returned on the
AuthenticationInfo from the previous method) is able to do. If you don't
want to implement authorization (ever, or yet), you can start with an
implementation like this:
@Override
protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
principals) {
SimpleAuthorizationInfo info = new SimpleAuthorizationInfo();
info.addStringPermission("*"); //THIS ALLOWS THE USER TO DO ANYTHING
return info;
}
Hope this helps.
Bryan Turner
Katasoft, Inc
-----Original Message-----
From: wmjasonward [mailto:[email protected]]
Sent: Tuesday, September 06, 2011 10:32 AM
To: [email protected]
Subject: Include domain in user authentication
I'm creating a webapp that will be white-labeled and I need to allow
different domains to have overlapping usernames. For example, www.a.com and
www.b.com could both have users named 'jason' even though both domains are
being serviced by the same underlying webapp (using Tomcat). The user
'jason' on domain www.b.com is a different person than the user 'jason' on
www.a.com.
Also, I'll be using a database to store user information. I prefer to work
with the Stable Shiro 1.1 but will consider moving up to Shiro 1.2 if it
makes this task easier and the functions I need are stable.
I'm just getting started with Shiro and am of course on a compressed
timeline so I'd appreciate any help getting me pointed in the right
direction on how to do this (wrap the filter, override the realm, etc.).
Thanks!
Jason
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Include-domain-in-user-authentication
-tp6764853p6764853.html
Sent from the Shiro User mailing list archive at Nabble.com.
