That's basically the same as what I did for a recently completed project. -- Eric
On Tue, Sep 6, 2011 at 7:33 PM, Bryan Turner <[email protected]> wrote: > 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.comand > 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. > >
