Bryan,
Thanks for the excellent description. It sounds like exactly what I need!
Our app has both a web gui and a REST api so I'll be using both form and
basic authentication but I should be able to extend both based on your
suggestion. I will be using Authorization but that should follow smoothly
once I have the domain (or in your case tenant) info attached.
Jason
Bryan Turner-2 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.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.
>
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Include-domain-in-user-authentication-tp6764853p6766091.html
Sent from the Shiro User mailing list archive at Nabble.com.