Change SecurityManager at runtime?

[Ryan McKinley <ry...@gmail.com>]

Hi-

I'm trying to get started with JSecurity/Ki and before chasing myself  
down the wrong path, i figured I would ask here first..  (BTW, is this  
the preferred location?  what about http://www.jsecurity.org/forum ?)

I have a wicket application where I need to offer a variety of  
authentication methods.  By default anyone can do anything, then users  
could enable security that will either pull authentication from JDBC  
or LDAP.

1.  Is it possible to change the SecurityManager/Realm configuration  
at runtime?  My plan is to configure a SecurityManager in the init()  
method, then potentially change it when users twiddle the settings  
(via UI).  Although I am running spring, I don't want users to have to  
configure spring to change the settings.

2. I need to apply authentication rules throughout my applicaiton, BUT  
by default let anyone do anything.  What is the recommend way to do  
this?  Use something already built? Implement a SecurityManager?  I  
could make a Realm with all known permissions, but that seems really  
brittle *and* it would not let me use "isAuthenticated()"

3. In the wicket examples [1], I am trying to add some debug info to  
help learn/understand what is going on.  I added a panel to show the  
contents of SecurityUtils.getSecurityManager().getClass() but it looks  
like that is not used by default (makes sense).  Is there a way to  
access the current SecurityManager?


[1] https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/ki-security/ki-security-examples/


Thanks for any pointers!

ryan

Re: Change SecurityManager at runtime?

[Ryan McKinley <ry...@gmail.com>]

On Mar 28, 2009, at 4:00 PM, Les Hazlewood wrote:

>> Sure, this is definitely possible, but its probably not necessary.   
>> You can configure multiple realms on the SecurityManager, and any  
>> number of them can participate in an authentication or  
>> authorization operation as desired.  An implementation of  
>> org.apache.ki.authc.pam.AuthenticationStrategy dictates how  
>> multiple realms are coordinated during an authentication attempt.   
>> There are a few implementations that exist already and might be  
>> suitable for your needs.
>>
>> Or you could create your own implementation customize what happens  
>> during an authentication attempt, or even easier, just program your  
>> Realm(s) to react differently depending on some application state  
>> or flag set a runtime.  Either way is fine.  The Realm-only  
>> approach limits your required knowledge of how Ki works, so I'd  
>> investigate that first.
>
> makes sense - thanks
>
> I will try implementing a "master" Realm that behaves differently  
> given the application state.  It may allow everything, or delegate  
> to other more complex Realms (LDAP etc)
>
> Hrm.  Realms should be thought of as DAOs with a 1:1 correspondence  
> with a back-end data store.  If you have a 'master realm', you start  
> to blur that line, in which case an AuthenticationStrategy makes  
> more sense - that is its purpose after all.
>
> But also note that a Realm can elect to not be consulted during  
> login.  If your supports(AuthenticationToken) method on a given  
> Realm always returns false, it will never be consulted for login,  
> and instead will be there only for authorization operations.
>
> Or the implementation of that method can change its return value  
> based on some runtime state:  You could make a subclass of  
> UsernamePasswordToken that wraps the state that trigger certain  
> login functionality and react to it in the supports(...) method or  
> other methods.  The state of the token (or some other shared state  
> based on other injected components) could enable your Realm  
> implementation to react as necessary.
>
> Either of these two points (or both together) might be a better  
> mechanism for your goals rather than writing a coordinating concept  
> like an AuthenticationStrategy.  But if you feel you must write  
> coordination logic, you should write an AuthenticationStrategy  
> implementation.
>

Ok, I think I understand things now.

Now my only problem is actually sorting out the mechanics of *how* to  
change the security manager at runtime.  I posted my feable attemts  
here:

https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/ki-security/ki-security-examples/ki-security-example-spring-jdbc

It has a button to switch between a "Full Access" account and the  
configured JDBC one.

It is not really working, but I would love any guidance on how to make  
it work :)

Thanks for all your help!

ryan


> Regards,
>
> Les
>

Re: Change SecurityManager at runtime?

[Les Hazlewood <lh...@apache.org>]

>
> Sure, this is definitely possible, but its probably not necessary.  You can
> configure multiple realms on the SecurityManager, and any number of them can
> participate in an authentication or authorization operation as desired.  An
> implementation of org.apache.ki.authc.pam.AuthenticationStrategy dictates
> how multiple realms are coordinated during an authentication attempt.  There
> are a few implementations that exist already and might be suitable for your
> needs.
>
> Or you could create your own implementation customize what happens during
> an authentication attempt, or even easier, just program your Realm(s) to
> react differently depending on some application state or flag set a
> runtime.  Either way is fine.  The Realm-only approach limits your required
> knowledge of how Ki works, so I'd investigate that first.
>
>
> makes sense - thanks
>
> I will try implementing a "master" Realm that behaves differently given the
> application state.  It may allow everything, or delegate to other more
> complex Realms (LDAP etc)
>

Hrm.  Realms should be thought of as DAOs with a 1:1 correspondence with a
back-end data store.  If you have a 'master realm', you start to blur that
line, in which case an AuthenticationStrategy makes more sense - that is its
purpose after all.

But also note that a Realm can elect to not be consulted during login.  If
your supports(AuthenticationToken) method on a given Realm always returns
false, it will never be consulted for login, and instead will be there only
for authorization operations.

Or the implementation of that method can change its return value based on
some runtime state:  You could make a subclass of UsernamePasswordToken that
wraps the state that trigger certain login functionality and react to it in
the supports(...) method or other methods.  The state of the token (or some
other shared state based on other injected components) could enable your
Realm implementation to react as necessary.

Either of these two points (or both together) might be a better mechanism
for your goals rather than writing a coordinating concept like an
AuthenticationStrategy.  But if you feel you must write coordination logic,
you should write an AuthenticationStrategy implementation.

Regards,

Les

Re: Change SecurityManager at runtime?

[Ryan McKinley <ry...@gmail.com>]

On Mar 28, 2009, at 3:15 PM, Les Hazlewood wrote:

> Hi Ryan,
>
> Please see in-line below.
>
> I'm trying to get started with JSecurity/Ki and before chasing  
> myself down the wrong path, i figured I would ask here first..   
> (BTW, is this the preferred location?  what about http://www.jsecurity.org/forum 
>  ?)
>
> The jsecurity.org site is older and should be marked as deprecated  
> now that we're an Apache Incubator project.  The forums aren't  
> watched as actively as the mailing lists.  jsecurity.org is really  
> only still online for archival purposes only.
>
> I have a wicket application where I need to offer a variety of  
> authentication methods.  By default anyone can do anything, then  
> users could enable security that will either pull authentication  
> from JDBC or LDAP.
> master
> 1.  Is it possible to change the SecurityManager/Realm configuration  
> at runtime?  My plan is to configure a SecurityManager in the init()  
> method, then potentially change it when users twiddle the settings  
> (via UI).  Although I am running spring, I don't want users to have  
> to configure spring to change the settings.
>
> Sure, this is definitely possible, but its probably not necessary.   
> You can configure multiple realms on the SecurityManager, and any  
> number of them can participate in an authentication or authorization  
> operation as desired.  An implementation of  
> org.apache.ki.authc.pam.AuthenticationStrategy dictates how multiple  
> realms are coordinated during an authentication attempt.  There are  
> a few implementations that exist already and might be suitable for  
> your needs.
>
> Or you could create your own implementation customize what happens  
> during an authentication attempt, or even easier, just program your  
> Realm(s) to react differently depending on some application state or  
> flag set a runtime.  Either way is fine.  The Realm-only approach  
> limits your required knowledge of how Ki works, so I'd investigate  
> that first.

makes sense - thanks

I will try implementing a "master" Realm that behaves differently  
given the application state.  It may allow everything, or delegate to  
other more complex Realms (LDAP etc)


>
> 2. I need to apply authentication rules throughout my applicaiton,  
> BUT by default let anyone do anything.  What is the recommend way to  
> do this?  Use something already built? Implement a SecurityManager?   
> I could make a Realm with all known permissions, but that seems  
> really brittle *and* it would not let me use "isAuthenticated()"
>
> I'm assuming you mean 'authorization' rules? i.e. who can do what  
> after they have already logged in (authenticated)?

yup -- still learning the terms :)   Ki has been great since (compared  
to other platforms) I can avoid much of the nitty gritty and still get  
something working.


>
> Authorization deals with checking roles and permissions, and the  
> security model in that regard, is entirely up to you.  If you wanted  
> anyone by default to do whatever they want, you could always program  
> an AuthorizingRealm subclass's doGetAuthorizationInfo method to  
> return a SimpleAuthorizationInfo object that wraps an  
> org.apache.ki.authz.permission.AllPermission instance.
>
> Then, as you restrict user's abilities, you can remove that  
> permission association from their account and specify other  
> permissions (can be string based as well - see the  
> org.apache.ki.authz.permission.WildcardPermission JavaDoc for more).
>
> As far as isAuthenticated(), which is entirely orthogonal to any of  
> the authorization methods, it is worth understanding the difference  
> between that and being remembered via 'rememberMe' services.  Look  
> at the Subject.isAuthenticated() JavaDoc and the  
> org.apache.ki.authc.RememberMeAuthenticationToken JavaDoc to  
> understand the subtle (yet very important) differences.

Yes, i just figured out this distinction -- after struggling to  
understand why things were not behaving as I expected I found the  
javadocs.

I added an "isAuthenticated" example to the base wicket example;  
hopefully it will be more clear for the next guy.


>
>
> 3. In the wicket examples [1], I am trying to add some debug info to  
> help learn/understand what is going on.  I added a panel to show the  
> contents of SecurityUtils.getSecurityManager().getClass() but it  
> looks like that is not used by default (makes sense).  Is there a  
> way to access the current SecurityManager?
>
> For the most part, you don't want to access the SecurityManager  
> directly, but rather use SecurityUtils.getSubject().  As long as  
> you're using the KiFilter in web.xml, you should always have access  
> to the currently executing Subject via that method.  You could  
> access the SecurityManager directly, but this is only really  
> necessary when writing lower-level framework integration code, such  
> as in remoting scenarious and federated security environments.
>
> I hope that helps!  Please let me know if we could be of any more  
> help.
>

Yes.  Thank you.


>

Re: Change SecurityManager at runtime?

[Les Hazlewood <lh...@apache.org>]

Hi Ryan,

Please see in-line below.

I'm trying to get started with JSecurity/Ki and before chasing myself down
> the wrong path, i figured I would ask here first..  (BTW, is this the
> preferred location?  what about http://www.jsecurity.org/forum ?)
>

The jsecurity.org site is older and should be marked as deprecated now that
we're an Apache Incubator project.  The forums aren't watched as actively as
the mailing lists.  jsecurity.org is really only still online for archival
purposes only.


> I have a wicket application where I need to offer a variety of
> authentication methods.  By default anyone can do anything, then users could
> enable security that will either pull authentication from JDBC or LDAP.
>
> 1.  Is it possible to change the SecurityManager/Realm configuration at
> runtime?  My plan is to configure a SecurityManager in the init() method,
> then potentially change it when users twiddle the settings (via UI).
>  Although I am running spring, I don't want users to have to configure
> spring to change the settings.
>

Sure, this is definitely possible, but its probably not necessary.  You can
configure multiple realms on the SecurityManager, and any number of them can
participate in an authentication or authorization operation as desired.  An
implementation of org.apache.ki.authc.pam.AuthenticationStrategy dictates
how multiple realms are coordinated during an authentication attempt.  There
are a few implementations that exist already and might be suitable for your
needs.

Or you could create your own implementation customize what happens during an
authentication attempt, or even easier, just program your Realm(s) to react
differently depending on some application state or flag set a runtime.
Either way is fine.  The Realm-only approach limits your required knowledge
of how Ki works, so I'd investigate that first.


> 2. I need to apply authentication rules throughout my applicaiton, BUT by
> default let anyone do anything.  What is the recommend way to do this?  Use
> something already built? Implement a SecurityManager?  I could make a Realm
> with all known permissions, but that seems really brittle *and* it would not
> let me use "isAuthenticated()"
>

I'm assuming you mean 'authorization' rules? i.e. who can do what after they
have already logged in (authenticated)?

Authorization deals with checking roles and permissions, and the security
model in that regard, is entirely up to you.  If you wanted anyone by
default to do whatever they want, you could always program an
AuthorizingRealm subclass's doGetAuthorizationInfo method to return a
SimpleAuthorizationInfo object that wraps an
org.apache.ki.authz.permission.AllPermission instance.

Then, as you restrict user's abilities, you can remove that permission
association from their account and specify other permissions (can be string
based as well - see the org.apache.ki.authz.permission.WildcardPermission
JavaDoc for more).

As far as isAuthenticated(), which is entirely orthogonal to any of the
authorization methods, it is worth understanding the difference between that
and being remembered via 'rememberMe' services.  Look at the
Subject.isAuthenticated() JavaDoc and the
org.apache.ki.authc.RememberMeAuthenticationToken JavaDoc to understand the
subtle (yet very important) differences.

3. In the wicket examples [1], I am trying to add some debug info to help
> learn/understand what is going on.  I added a panel to show the contents of
> SecurityUtils.getSecurityManager().getClass() but it looks like that is
> not used by default (makes sense).  Is there a way to access the current
> SecurityManager?
>

For the most part, you don't want to access the SecurityManager directly,
but rather use SecurityUtils.getSubject().  As long as you're using the
KiFilter in web.xml, you should always have access to the currently
executing Subject via that method.  You could access the SecurityManager
directly, but this is only really necessary when writing lower-level
framework integration code, such as in remoting scenarious and federated
security environments.

I hope that helps!  Please let me know if we could be of any more help.

Cheers,

Les

[1]
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/ki-security/ki-security-examples/
>