You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by midiman <pe...@gmail.com> on 2016/01/28 20:50:26 UTC
Change Shiro configuration at runtime
Hello Shiro Forum,
Trying to get shiro (web-based via web.xml + .ini file) to recognize changes
to the .ini file configuration without having to restart the web app.
Can anyone give some insight on best-practice to achieve this?
Many thanks, Peter
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by midiman <pe...@gmail.com>.
Hi, Yes got it, thanks.
The problem here is that I'm not creating users, I'm changing their roles,
which falls under the same category you've cited. Maybe lost in translation
in the docs.
I believe the solution in this case is to write a Custom Realm that can read
the (potentially dynamically changing) users, roles, permissions etc. from
my Java SealedObjects.
Jdbc is out as we don't use any.
Thank you for your help and responses - it's been very useful!
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580933.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
From Shiro documentation:
http://shiro.apache.org/configuration.html#Configuration-%5Cusers%5C
The [users] section allows you to define a static set of user accounts. This is mostly useful in environments with a very small number of user accounts or where user accounts don't need to be created dynamically at runtime. Here's an example:
As you can see, the documentation clearly states that specifying users / roles in shiro.ini is not meant to be used in a dynamic environment, which is what you have.
On the other hand Jdbc/Custom realm or Stormpath is precisely for that account.
The portion of the documentation you are reading is for “quick start” only.
> On Jan 28, 2016, at 4:06 PM, midiman <pe...@gmail.com> wrote:
>
> Hi,
> Many thanks for the clarification to use JDBC/StormPath etc. I suppose there
> must be some implementation reason for having ini being treated differently.
>> From a security perspective, there's no real difference between a back-end
> jdbc connector and an ini file. Without some strong encryption, they're both
> as insecure as each other.
> Thanks for your help!
> Peter
>
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580931.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Change Shiro configuration at runtime
Posted by midiman <pe...@gmail.com>.
Hi,
Many thanks for the clarification to use JDBC/StormPath etc. I suppose there
must be some implementation reason for having ini being treated differently.
>From a security perspective, there's no real difference between a back-end
jdbc connector and an ini file. Without some strong encryption, they're both
as insecure as each other.
Thanks for your help!
Peter
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580931.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
If you have JdbcRealm / CustomRealm / Stormpath as your
data store, you would have the exact solution you desire.
shiro.ini is considered a “read-only” initialization file, and not a substitute for a data store.
> On Jan 28, 2016, at 3:56 PM, midiman <pe...@gmail.com> wrote:
>
> Hi,
> Yeah, restarting the web app I can do - but that's not a real solution for a
> production system.
>
> The Use Case is simple, and I would have thought very common:
> * Start the web app
> * Load the RBAC system
> * Admin changes roles/permissions (in my case it's outside the web app for
> security, but could just as easily be within the app)
> * RBAC flushes/reinitializes to reflect the changes in the running web app
> * Web app carries on running
>
> Surely every web app in the world would want to do this, yes?
>
> If I added a new user to this mailing list as a sysop, I wouldn't want to
> bring Nabble down for those user changes to take effect?
> If I do it programmatically via the API, that's extra coding logic that
> shouldn't need to be in the app code. Moreover, that logic would be separate
> from the persistent state (e.g. ini or db) when the app does restart (e.g.
> after system maintenance reboot). Having to do the configuration twice -
> once persistently and once via runtime api isn't an ideal way to solve this
> problem.
>
> You must have come across this when using Shiro (or any rbac). How have you
> solved this if Shiro doesn't have a built-in mechanism? Maybe I'm missing
> something from the Shiro docs - I've had a good look through but there is no
> information on this subject.
>
> Thanks,
> Peter
>
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580928.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Change Shiro configuration at runtime
Posted by midiman <pe...@gmail.com>.
Hi,
Yeah, restarting the web app I can do - but that's not a real solution for a
production system.
The Use Case is simple, and I would have thought very common:
* Start the web app
* Load the RBAC system
* Admin changes roles/permissions (in my case it's outside the web app for
security, but could just as easily be within the app)
* RBAC flushes/reinitializes to reflect the changes in the running web app
* Web app carries on running
Surely every web app in the world would want to do this, yes?
If I added a new user to this mailing list as a sysop, I wouldn't want to
bring Nabble down for those user changes to take effect?
If I do it programmatically via the API, that's extra coding logic that
shouldn't need to be in the app code. Moreover, that logic would be separate
from the persistent state (e.g. ini or db) when the app does restart (e.g.
after system maintenance reboot). Having to do the configuration twice -
once persistently and once via runtime api isn't an ideal way to solve this
problem.
You must have come across this when using Shiro (or any rbac). How have you
solved this if Shiro doesn't have a built-in mechanism? Maybe I'm missing
something from the Shiro docs - I've had a good look through but there is no
information on this subject.
Thanks,
Peter
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580928.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by Brian Demers <br...@gmail.com>.
if you are doing this for development reasons, there are tools that will
restart your webapp for you.
such as:
https://www.eclipse.org/jetty/documentation/9.3.0.v20150612/jetty-maven-plugin.html
Can you give us a bit more info on your use-case for doing this?
On Thu, Jan 28, 2016 at 3:32 PM, Lenny Primak <lp...@hope.nyc.ny.us>
wrote:
> As far as I can tell, this is not something that is supported, for many
> important reasons.
> You can always set any security object dynamically at runtime, if you wish.
> Re-reading shiro.ini could introduce security risks IMHO.
>
> Why do you want this anyway? Seems very non-standard to me.
>
> > On Jan 28, 2016, at 1:50 PM, midiman <pe...@gmail.com> wrote:
> >
> > Hello Shiro Forum,
> >
> > Trying to get shiro (web-based via web.xml + .ini file) to recognize
> changes
> > to the .ini file configuration without having to restart the web app.
> >
> > Can anyone give some insight on best-practice to achieve this?
> >
> > Many thanks, Peter
> >
> >
> >
> >
> > --
> > View this message in context:
> http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921.html
> > Sent from the Shiro User mailing list archive at Nabble.com.
> >
>
>
Re: Change Shiro configuration at runtime
Posted by midiman <pe...@gmail.com>.
Agreed.
But if ini isn't the way to do it, why are the Shiro docs targeted squarely
at ini?
I have no problem with ini files, they are just as [in]secure as any
database mechanism.
But I'm not storing user data in the ini - just [users] and [roles] sections
exactly as the docs describe it (except I leave out passwords, as that is
truly insecure).
Seems unusual to have docs to describe a method that should not be used.
Thanks
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580930.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
I think you need to poke around some more in this stuff to get a better understanding of the design.
shiro.ini is not the appropriate place to keep actual user data, and Shiro isn’t designed to do this in production.
> On Jan 28, 2016, at 3:39 PM, midiman <pe...@gmail.com> wrote:
>
> I would certainly agree the ini file method isn't the most secure place to
> store roles (note I don't don't use it for authentication, only
> authorization).
> But the storage medium is surely independant from Shiro's
> reading/[re]loading of that medium. After all, a database can be hacked just
> as easily as an ini file.
> So are you saying that if I used a datastore instead of an ini file Shiro
> will automatically update itself when the datastore roles/permissions change
> within that datastore??
>
> With regards Realms (as opposed to config), I have noticed that the docs say
> a default Realm (in my case an IniRealm) is created if none is explicitly
> specified. But I have found that when I query the SecurityManager, there are
> no realms returned from getRealms() (returns null). Maybe the 'default' one
> is hidden (name is meant to be 'iniRealm' according to the docs for Shiro
> 1.2).
> I tried creating an explicit IniRealm in the ini file [main] section, but it
> failed. Maybe org.apache.shiro.realm.text.IniRealm is stopped from being
> loaded for some reason.
>
> Thanks
>
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580926.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Change Shiro configuration at runtime
Posted by midiman <pe...@gmail.com>.
I would certainly agree the ini file method isn't the most secure place to
store roles (note I don't don't use it for authentication, only
authorization).
But the storage medium is surely independant from Shiro's
reading/[re]loading of that medium. After all, a database can be hacked just
as easily as an ini file.
So are you saying that if I used a datastore instead of an ini file Shiro
will automatically update itself when the datastore roles/permissions change
within that datastore??
With regards Realms (as opposed to config), I have noticed that the docs say
a default Realm (in my case an IniRealm) is created if none is explicitly
specified. But I have found that when I query the SecurityManager, there are
no realms returned from getRealms() (returns null). Maybe the 'default' one
is hidden (name is meant to be 'iniRealm' according to the docs for Shiro
1.2).
I tried creating an explicit IniRealm in the ini file [main] section, but it
failed. Maybe org.apache.shiro.realm.text.IniRealm is stopped from being
loaded for some reason.
Thanks
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580926.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Storing roles / permissions / etc. in shiro.ini is a bad practice, and is shown in the docs for simplicity only.
In production system, any roles / permissions, etc. would be stored in a data store, not shiro.ini,
and thus would not require any changes to the application when users / roles change.
You can use JdbcRealm, custom realm or Sormpath for the above data store.
> On Jan 28, 2016, at 3:13 PM, midiman <pe...@gmail.com> wrote:
>
> Hi,
> Many thanks for your quick reply!
>
> It's an interesting take on it.
> I guess I look at this the other way round - I would have thought this would
> not only be standard, it would be needed in 90-100% of Use Cases.
> In a web environment, and in particular a role-based one, you'll have
> admins, users, guests, etc.
> The admins will typically have rights to change the roles/permissions of
> other users.
> So let's say for example the admin changes the guest user's role from one
> that can read some stuff to one that can read all stuff.
> The changes, in this case are going into an ini file (in a secure area on
> the web server's file system, so there's no additional security risks that
> aren't there at startup) but it could equally be anywhere else - db or
> similar. Now the rbac configuration is changed, but Shiro doesn't take these
> changes until the web app is restarted.
> In a production environment, restarting a web app just to apply some
> permission changes for one user isn't really ideal. Flushing a cache and/or
> re-initializing would be the expected behaviour.
> I would have thought that just about all implementations of shiro would, at
> some point, want to change the configuration, but without needing to restart
> their app (unless it's a standalone/short-lived app - e.g. desktop calendar
> app or similar).
> Interestingly, when I use shiro in a non-web environment (i.e. not using
> web.xml) it does reload changes to the ini file. But when loaded via a web
> container (I'm using Jetty 8.1), it doesn't.
> Yes, I can programmatically detect the changes, reload permissions etc. but
> that feels a lot like writing my own rbac system, there seems no need for it
> when shiro could (or should) just reinit itself, and carry on.
> I'm really surprised Shiro wouldn't have a [strightforward] mechanism to
> perform runtime config changes.
>
> Before asking this question, I had a search around as I figured this is a
> very common use case. There are lots of questions asking about this. Yours,
> so far, is the only answer (and I thank you for that)!
>
> Many thanks
> Peter
>
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580924.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Change Shiro configuration at runtime
Posted by midiman <pe...@gmail.com>.
Hi,
Many thanks for your quick reply!
It's an interesting take on it.
I guess I look at this the other way round - I would have thought this would
not only be standard, it would be needed in 90-100% of Use Cases.
In a web environment, and in particular a role-based one, you'll have
admins, users, guests, etc.
The admins will typically have rights to change the roles/permissions of
other users.
So let's say for example the admin changes the guest user's role from one
that can read some stuff to one that can read all stuff.
The changes, in this case are going into an ini file (in a secure area on
the web server's file system, so there's no additional security risks that
aren't there at startup) but it could equally be anywhere else - db or
similar. Now the rbac configuration is changed, but Shiro doesn't take these
changes until the web app is restarted.
In a production environment, restarting a web app just to apply some
permission changes for one user isn't really ideal. Flushing a cache and/or
re-initializing would be the expected behaviour.
I would have thought that just about all implementations of shiro would, at
some point, want to change the configuration, but without needing to restart
their app (unless it's a standalone/short-lived app - e.g. desktop calendar
app or similar).
Interestingly, when I use shiro in a non-web environment (i.e. not using
web.xml) it does reload changes to the ini file. But when loaded via a web
container (I'm using Jetty 8.1), it doesn't.
Yes, I can programmatically detect the changes, reload permissions etc. but
that feels a lot like writing my own rbac system, there seems no need for it
when shiro could (or should) just reinit itself, and carry on.
I'm really surprised Shiro wouldn't have a [strightforward] mechanism to
perform runtime config changes.
Before asking this question, I had a search around as I figured this is a
very common use case. There are lots of questions asking about this. Yours,
so far, is the only answer (and I thank you for that)!
Many thanks
Peter
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921p7580924.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Change Shiro configuration at runtime
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
As far as I can tell, this is not something that is supported, for many important reasons.
You can always set any security object dynamically at runtime, if you wish.
Re-reading shiro.ini could introduce security risks IMHO.
Why do you want this anyway? Seems very non-standard to me.
> On Jan 28, 2016, at 1:50 PM, midiman <pe...@gmail.com> wrote:
>
> Hello Shiro Forum,
>
> Trying to get shiro (web-based via web.xml + .ini file) to recognize changes
> to the .ini file configuration without having to restart the web app.
>
> Can anyone give some insight on best-practice to achieve this?
>
> Many thanks, Peter
>
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Change-Shiro-configuration-at-runtime-tp7580921.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>