You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Christian Schröder <ne...@l7010.de> on 2009/06/14 13:39:05 UTC
adding multiple logins (against different realms)
Hello,
i was wondering what is a common way to add permissions and principals
to the current subject.
in our web application there are semi-private urls (a long non guessable
hash) which are used to grant anonymous users access to this resource.
solutions i can think of:
1 special Token and realm and then using subject.login()
+ easy to do
+ logins can happen at different times and in different order
- multiple logins overwrite each other with the DefaultsecurityManager
2 having a list of "collected" keys in a principal
+ seems reasonable
- need to invalidate authorizationcaches
- principals would have to be merged manually on every login
Solution 1 seems to need a new securitymanager which overwrites
protected Subject createSubject(AuthenticationToken token,
AuthenticationInfo info)
to have the possibilty to have multiple logins which add information to
the current subject and not create a new subject. That way i could go
with multiple realms and multiple logins to achieve my goal. this seems
also a best fit to the problem domain.
On a side not this would make remember me easier too, (being just a
special realm and not spread in the securitymanager).
Is this a reasonable approach? Or is there some kind of best practice
already?
some cases to make this clearer (hopefully):
anonymous -> special url for object -> ACCESS to object
loggedin -> NO ACCESS to object
loggedin as author of object -> ACCESS to object
loggedin -> special url for object -> ACCESS to object
anonymous -> special url for object -> login -> ACCESS to object
the last case requires this new Default Security Manager
regards
Christian
Re: adding multiple logins (against different realms)
Posted by Christian Schröder <ne...@l7010.de>.
Les Hazlewood schrieb:
> Hi Christian,
>
> Typically you don't need to create subclasses of the SecurityManager - you
> can set up multiple Realms, and each realm can choose to participate in the
> login or not by inspecting the AuthenticationToken. The principals from all
> realms are combined after log-in as an aggregate to represent the Subject's
> identity - they typically don't 'overwrite' each other.
>
> If you need very fine-grained control over how Realms are consulted and the
> aggregate AuthenticationInfo is constructed, you could always inject your
> own AuthenticationStrategy into the SecurityManager. Your implementation
> would create the aggregate AuthenticationInfo object however you desire.
> Check out all the existing AuthenticationStrategy implementations first
> before you spend too much time on that though - there may be something that
> you already need.
>
> Specifically, the 'AtLeastOneSuccessful' strategy might be what you want.
yeah i tried it and didn˚t like the working result :o so i rethought and
came to a solution like this:
right now i just manipulate the principalcollection of the current
subject and let my special url realm add the special urls as
SpecialPrincipals to it.
And on authentication my realm gets all relevant principals from the
current subject and puts ˚em in the AuthenticationInfo, so they will get
aggregated too
To find out if the user is authenticated (really logged in) i use a Role
and check for that.
looking at the code this looks nicer to me :)
regards and thx for your feedback
Christian
Re: adding multiple logins (against different realms)
Posted by Les Hazlewood <lh...@apache.org>.
Hi Christian,
Typically you don't need to create subclasses of the SecurityManager - you
can set up multiple Realms, and each realm can choose to participate in the
login or not by inspecting the AuthenticationToken. The principals from all
realms are combined after log-in as an aggregate to represent the Subject's
identity - they typically don't 'overwrite' each other.
If you need very fine-grained control over how Realms are consulted and the
aggregate AuthenticationInfo is constructed, you could always inject your
own AuthenticationStrategy into the SecurityManager. Your implementation
would create the aggregate AuthenticationInfo object however you desire.
Check out all the existing AuthenticationStrategy implementations first
before you spend too much time on that though - there may be something that
you already need.
Specifically, the 'AtLeastOneSuccessful' strategy might be what you want.
Best regards,
Les
On Sun, Jun 14, 2009 at 7:39 AM, Christian Schröder <ne...@l7010.de> wrote:
> Hello,
> i was wondering what is a common way to add permissions and principals
> to the current subject.
>
> in our web application there are semi-private urls (a long non guessable
> hash) which are used to grant anonymous users access to this resource.
>
> solutions i can think of:
> 1 special Token and realm and then using subject.login()
> + easy to do
> + logins can happen at different times and in different order
> - multiple logins overwrite each other with the DefaultsecurityManager
> 2 having a list of "collected" keys in a principal
> + seems reasonable
> - need to invalidate authorizationcaches
> - principals would have to be merged manually on every login
>
> Solution 1 seems to need a new securitymanager which overwrites
>
> protected Subject createSubject(AuthenticationToken token,
> AuthenticationInfo info)
>
> to have the possibilty to have multiple logins which add information to
> the current subject and not create a new subject. That way i could go
> with multiple realms and multiple logins to achieve my goal. this seems
> also a best fit to the problem domain.
>
> On a side not this would make remember me easier too, (being just a
> special realm and not spread in the securitymanager).
>
> Is this a reasonable approach? Or is there some kind of best practice
> already?
>
> some cases to make this clearer (hopefully):
> anonymous -> special url for object -> ACCESS to object
> loggedin -> NO ACCESS to object
> loggedin as author of object -> ACCESS to object
> loggedin -> special url for object -> ACCESS to object
> anonymous -> special url for object -> login -> ACCESS to object
>
> the last case requires this new Default Security Manager
>
>
> regards
> Christian
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFKNN3bd1zGxPhGhFcRA71vAKDQPhZlJ+bJtb4hQTQg/J1e7uazbgCeKBQK
> kNClnmjSvqnL7Ho6XZs/ubw=
> =/lux
> -----END PGP SIGNATURE-----
>
>
>