You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by aloleary <al...@gmail.com> on 2009/11/03 19:14:28 UTC

Standalone Environment

Hello, 
   Just starting to use Shiro in a standlone application and I really like
what I have seen so far. I just have a couple of questions:

1) Is the standalone capability going to be supported going forward - I can
see it's documented as very much a developer aid but it fits very well into
standalone single vm/lightweight apps.

2) once i have authenticated/logged in... i have a requirement to pull out
the actual username and password for the subject later in the application
(to construct credentials for httpbasic auth requests)

Is there any 'shiro way' to do this ? 

		UsernamePasswordToken token = new UsernamePasswordToken("root", "secret"
);
		token.setRememberMe(true);
		Subject currentUser = SecurityUtils.getSubject();
		currentUser.login(token);
                ....

                // somewhere else in code
                Subject currentUser = SecurityUtils.getSubject();
                ... ?? how to get users username and password in code ???

Currently investigating using Shiro in a Swing & JavaFX application - so far
so good !

-A-


-- 
View this message in context: http://n2.nabble.com/Standalone-Environment-tp3940226p3940226.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Standalone Environment

Posted by Les Hazlewood <lh...@apache.org>.
Hi Al,

There hasn't been much work on the Guice-specific integration, but
we're very open to submissions.  If you're willing to contribute even
a little bit toward that area, please feel free to help out!

Regards,

Les

On Tue, Nov 3, 2009 at 2:07 PM, aloleary <al...@gmail.com> wrote:
>
> Perfect - I am getting the data back out of my own model as you described
> below so good to know on the right track - as I'm very new to Shiro was just
> checking if there was anything cached or somewhere in the
> PrincipalCollection etc .. esp in standalone mode that I might have missed -
> but I guess thinking about it that wouldn't be very secure !
>
> One other area I am very interested in is the progress with Guice.. not in
> the web context as described in
> http://issues.apache.org/jira/browse/SHIRO-23 but in the standalone/non
> web.xml environment
>
> Thanks for the quick response,
> -A-
>
>
> Les Hazlewood-2 wrote:
>>
>> Hi Al,
>>
>> Yep, Shiro will continue to be supported in standalone applications as
>> well as any other environment we are able to support. :)
>>
>> When you authenticate a user with the UsernamePasswordToken, the
>> underlying Realm returns a PrincipalCollection that will be used to
>> identify the Subject at runtime.  Each realm returns a
>> PrincipalCollection to retain principals it 'knows' about and that the
>> application might use.  If multiple Realms are configured,  the
>> principals from all realms are aggregated into a 'bundle'
>> PrincipalCollection and that is used.  If one realm is configured,
>> that realm's PrincipalCollection is used directly.
>>
>> No matter how many principals across realms there might be, typically
>> you'll have a 'primary' principal that identifies the user across the
>> entire application.  Shiro's default heuristic in determining that
>> 'primary' value is just to assume that the first principal returned by
>> the very first Realm is the 'primary' one for the entire application.
>>
>> A simple Realm implementation could have its doGetAuthenticationInfo
>> return the following:
>>
>> new SimplePrincipalCollection(username, password, getName());
>>
>> If this is the only Realm consulted during authentication, then the
>> following call:
>>
>> subject.getPrincipal();
>>
>> will return the username (because it is the Realm's
>> PrincipalCollection's first value).
>>
>> When you get that username, you'll have to do a query against your
>> datasource that backs the realm for any additional information for
>> that user keyed off of the username.
>>
>> This is a simple example.  Another approach is to have that principal
>> be a user ID instead (for example, a surrogate primary key in a
>> 'users' rdbms table):
>>
>> User user = queryForUser(usernamePasswordToken);
>> return new SimplePrincipalCollection(user.getId(), user.getPassword(),
>> getName());
>>
>> Now when you call subject.getPrincipal() it will return the value of
>> user.getId().
>>
>> You might then do this in your application code:
>>
>> User user = userService.getUser((Long)subject.getPrincipal());
>>
>> which will typically result in a faster query execution due to the
>> primary key lookup.
>>
>> Which approach you choose is entirely up to you - you could store
>> anything you want in the PrincipalCollection (username, userId, first
>> name, last name, etc).  Most people almost always use a unique key
>> such as a user id or username and look up other user data based on
>> that key, relying on things like caching to ensure those lookups
>> remain as fast as possible for the application.
>>
>> I hope that helps!
>>
>> Cheers,
>>
>> Les
>>
>> On Tue, Nov 3, 2009 at 1:14 PM, aloleary <al...@gmail.com> wrote:
>>>
>>> Hello,
>>>   Just starting to use Shiro in a standlone application and I really like
>>> what I have seen so far. I just have a couple of questions:
>>>
>>> 1) Is the standalone capability going to be supported going forward - I
>>> can
>>> see it's documented as very much a developer aid but it fits very well
>>> into
>>> standalone single vm/lightweight apps.
>>>
>>> 2) once i have authenticated/logged in... i have a requirement to pull
>>> out
>>> the actual username and password for the subject later in the application
>>> (to construct credentials for httpbasic auth requests)
>>>
>>> Is there any 'shiro way' to do this ?
>>>
>>>                UsernamePasswordToken token = new
>>> UsernamePasswordToken("root", "secret"
>>> );
>>>                token.setRememberMe(true);
>>>                Subject currentUser = SecurityUtils.getSubject();
>>>                currentUser.login(token);
>>>                ....
>>>
>>>                // somewhere else in code
>>>                Subject currentUser = SecurityUtils.getSubject();
>>>                ... ?? how to get users username and password in code ???
>>>
>>> Currently investigating using Shiro in a Swing & JavaFX application - so
>>> far
>>> so good !
>>>
>>> -A-
>>>
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Standalone-Environment-tp3940226p3940226.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/Standalone-Environment-tp3940226p3940589.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Standalone Environment

Posted by aloleary <al...@gmail.com>.
Perfect - I am getting the data back out of my own model as you described
below so good to know on the right track - as I'm very new to Shiro was just
checking if there was anything cached or somewhere in the
PrincipalCollection etc .. esp in standalone mode that I might have missed -
but I guess thinking about it that wouldn't be very secure !

One other area I am very interested in is the progress with Guice.. not in
the web context as described in
http://issues.apache.org/jira/browse/SHIRO-23 but in the standalone/non
web.xml environment

Thanks for the quick response,
-A-


Les Hazlewood-2 wrote:
> 
> Hi Al,
> 
> Yep, Shiro will continue to be supported in standalone applications as
> well as any other environment we are able to support. :)
> 
> When you authenticate a user with the UsernamePasswordToken, the
> underlying Realm returns a PrincipalCollection that will be used to
> identify the Subject at runtime.  Each realm returns a
> PrincipalCollection to retain principals it 'knows' about and that the
> application might use.  If multiple Realms are configured,  the
> principals from all realms are aggregated into a 'bundle'
> PrincipalCollection and that is used.  If one realm is configured,
> that realm's PrincipalCollection is used directly.
> 
> No matter how many principals across realms there might be, typically
> you'll have a 'primary' principal that identifies the user across the
> entire application.  Shiro's default heuristic in determining that
> 'primary' value is just to assume that the first principal returned by
> the very first Realm is the 'primary' one for the entire application.
> 
> A simple Realm implementation could have its doGetAuthenticationInfo
> return the following:
> 
> new SimplePrincipalCollection(username, password, getName());
> 
> If this is the only Realm consulted during authentication, then the
> following call:
> 
> subject.getPrincipal();
> 
> will return the username (because it is the Realm's
> PrincipalCollection's first value).
> 
> When you get that username, you'll have to do a query against your
> datasource that backs the realm for any additional information for
> that user keyed off of the username.
> 
> This is a simple example.  Another approach is to have that principal
> be a user ID instead (for example, a surrogate primary key in a
> 'users' rdbms table):
> 
> User user = queryForUser(usernamePasswordToken);
> return new SimplePrincipalCollection(user.getId(), user.getPassword(),
> getName());
> 
> Now when you call subject.getPrincipal() it will return the value of
> user.getId().
> 
> You might then do this in your application code:
> 
> User user = userService.getUser((Long)subject.getPrincipal());
> 
> which will typically result in a faster query execution due to the
> primary key lookup.
> 
> Which approach you choose is entirely up to you - you could store
> anything you want in the PrincipalCollection (username, userId, first
> name, last name, etc).  Most people almost always use a unique key
> such as a user id or username and look up other user data based on
> that key, relying on things like caching to ensure those lookups
> remain as fast as possible for the application.
> 
> I hope that helps!
> 
> Cheers,
> 
> Les
> 
> On Tue, Nov 3, 2009 at 1:14 PM, aloleary <al...@gmail.com> wrote:
>>
>> Hello,
>>   Just starting to use Shiro in a standlone application and I really like
>> what I have seen so far. I just have a couple of questions:
>>
>> 1) Is the standalone capability going to be supported going forward - I
>> can
>> see it's documented as very much a developer aid but it fits very well
>> into
>> standalone single vm/lightweight apps.
>>
>> 2) once i have authenticated/logged in... i have a requirement to pull
>> out
>> the actual username and password for the subject later in the application
>> (to construct credentials for httpbasic auth requests)
>>
>> Is there any 'shiro way' to do this ?
>>
>>                UsernamePasswordToken token = new
>> UsernamePasswordToken("root", "secret"
>> );
>>                token.setRememberMe(true);
>>                Subject currentUser = SecurityUtils.getSubject();
>>                currentUser.login(token);
>>                ....
>>
>>                // somewhere else in code
>>                Subject currentUser = SecurityUtils.getSubject();
>>                ... ?? how to get users username and password in code ???
>>
>> Currently investigating using Shiro in a Swing & JavaFX application - so
>> far
>> so good !
>>
>> -A-
>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/Standalone-Environment-tp3940226p3940226.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
> 
> 

-- 
View this message in context: http://n2.nabble.com/Standalone-Environment-tp3940226p3940589.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Standalone Environment

Posted by Les Hazlewood <lh...@apache.org>.
Hi Al,

Yep, Shiro will continue to be supported in standalone applications as
well as any other environment we are able to support. :)

When you authenticate a user with the UsernamePasswordToken, the
underlying Realm returns a PrincipalCollection that will be used to
identify the Subject at runtime.  Each realm returns a
PrincipalCollection to retain principals it 'knows' about and that the
application might use.  If multiple Realms are configured,  the
principals from all realms are aggregated into a 'bundle'
PrincipalCollection and that is used.  If one realm is configured,
that realm's PrincipalCollection is used directly.

No matter how many principals across realms there might be, typically
you'll have a 'primary' principal that identifies the user across the
entire application.  Shiro's default heuristic in determining that
'primary' value is just to assume that the first principal returned by
the very first Realm is the 'primary' one for the entire application.

A simple Realm implementation could have its doGetAuthenticationInfo
return the following:

new SimplePrincipalCollection(username, password, getName());

If this is the only Realm consulted during authentication, then the
following call:

subject.getPrincipal();

will return the username (because it is the Realm's
PrincipalCollection's first value).

When you get that username, you'll have to do a query against your
datasource that backs the realm for any additional information for
that user keyed off of the username.

This is a simple example.  Another approach is to have that principal
be a user ID instead (for example, a surrogate primary key in a
'users' rdbms table):

User user = queryForUser(usernamePasswordToken);
return new SimplePrincipalCollection(user.getId(), user.getPassword(),
getName());

Now when you call subject.getPrincipal() it will return the value of
user.getId().

You might then do this in your application code:

User user = userService.getUser((Long)subject.getPrincipal());

which will typically result in a faster query execution due to the
primary key lookup.

Which approach you choose is entirely up to you - you could store
anything you want in the PrincipalCollection (username, userId, first
name, last name, etc).  Most people almost always use a unique key
such as a user id or username and look up other user data based on
that key, relying on things like caching to ensure those lookups
remain as fast as possible for the application.

I hope that helps!

Cheers,

Les

On Tue, Nov 3, 2009 at 1:14 PM, aloleary <al...@gmail.com> wrote:
>
> Hello,
>   Just starting to use Shiro in a standlone application and I really like
> what I have seen so far. I just have a couple of questions:
>
> 1) Is the standalone capability going to be supported going forward - I can
> see it's documented as very much a developer aid but it fits very well into
> standalone single vm/lightweight apps.
>
> 2) once i have authenticated/logged in... i have a requirement to pull out
> the actual username and password for the subject later in the application
> (to construct credentials for httpbasic auth requests)
>
> Is there any 'shiro way' to do this ?
>
>                UsernamePasswordToken token = new UsernamePasswordToken("root", "secret"
> );
>                token.setRememberMe(true);
>                Subject currentUser = SecurityUtils.getSubject();
>                currentUser.login(token);
>                ....
>
>                // somewhere else in code
>                Subject currentUser = SecurityUtils.getSubject();
>                ... ?? how to get users username and password in code ???
>
> Currently investigating using Shiro in a Swing & JavaFX application - so far
> so good !
>
> -A-
>
>
> --
> View this message in context: http://n2.nabble.com/Standalone-Environment-tp3940226p3940226.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>