Mailing-List: contact jsecurity-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jsecurity-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jhaile@fastmail.fm designates
 66.111.4.25 as permitted sender)
Message-Id: <0D1344AA-479E-4A27-B8F7-24F732C456DE@fastmail.fm>
From: Jeremy Haile <jhaile@fastmail.fm>
To: jsecurity-user@incubator.apache.org
In-Reply-To: <181042e30812150157v4575d2f7h584707fb77c88bf5@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: super user
Date: Mon, 15 Dec 2008 09:18:30 -0500
References: <181042e30812150157v4575d2f7h584707fb77c88bf5@mail.gmail.com>

Animesh,

You can definitely support super user authentication with JSecurity -  
we do this in our application.  The way we do it is by having our  
realm accept multiple types of tokens - a regular  
UsernamePasswordToken and also a SuperUserToken.  The SuperUserToken  
contains an additional field called "runAsUser".  (in other words, it  
has a username, password, and a "run as username" property)

The realm will then authenticate the normal username and password, but  
return back the principal of the "run as user".  Since our realm  
extends from AuthorizingRealm, it simply returns an instance of  
SimpleAuthenticationInfo that contains the principal of the "run as  
user" but the credentials of the user who is authenticating.

Since this is potentially a very dangerous feature, we only enable it  
for accounts that have the admin flag set on them and ensure that the  
password for this account is very secure, limited, and changed on a  
regular basis.  This functionality is also only available from a  
secret URL that we don't link to in any way.

Here's an excerpt code snippet from our codebase:

User user = userManager.getActiveUserByEmail( organizationId,  
token.getUsername());
if( user == null ) {
     throw new UnknownAccountException( "No user account found for ["  
+ token.getUsername() + "] for org ID [" + organizationId + "]" );
}

  if( token instanceof SuperUserToken ) {
             if( !user.isAdmin() ) {
                 final String message = "Attempt to login as superuser  
by non-admin account: [" + token.getUsername() + "]";
                 log.error(message);
                 throw new UnauthorizedException( message );
             }

             Contact runAsContact =  
contactManager 
.getContactByEmail( ((SuperUserToken)token).getRunAsEmail() );
             if( runAsContact == null ) {
                 throw new UnknownAccountException( "No user found  
with email [" + ((SuperUserToken)token).getRunAsEmail() + "]" );
             }
             UserPrincipal runAsPrincipal = new  
UserPrincipal(runAsContact.getUser().getId(), runAsContact.getId());
             return new SimpleAuthenticationInfo( runAsPrincipal,  
user.getEncryptedPassword(), getName() );

  } else {
  // Do regular authentication here...
}

Let me know if you have any questions or problems with this approach.

Jeremy Haile


On Dec 15, 2008, at 4:57 AM, Animesh Jain wrote:

> Hi
>
> Is there some way to create a super user sort of entity which can  
> authenticate itself as any subject it wants. It probably is not  
> desired to have such functionality but I'm wondering if there's some  
> way to achieve that if needed.
>
> Kind regards
> Animesh