You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Fernando Wermus <fe...@gmail.com> on 2010/11/21 16:21:35 UTC
shiro + wicket + backend
Hi all,
I am using shiro successfully with wicket. But I need to develop
authorization for services in the backend. I am thinking of using some kind
of interceptor, which authorizes the called. We don't use spring and we need
to find a way to develop it with the minimun effort. Is there any solution
that not take into account spring for security and has its all benefits? Or
should we integrate our app with spring?
thanks in advance
--
Fernando Wermus.
www.linkedin.com/in/fernandowermus
Re: shiro + wicket + backend
Posted by Les Hazlewood <lh...@apache.org>.
P.S. I just realized I'm still subscribed to Wicket's user and dev lists.
On Mon, Nov 29, 2010 at 2:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> Since there are people using wicketstuff shiro integration already, I
>>> think it'd be nice to have a new major version of the shiro parts if
>>> the changes will be large. This way the existing community has an
>>> obvious upgrade path without causing confusion. If it is perceived
>>> that there is more than one wicket-shiro project, it would probably
>>> frustrate and/or fragment the community rather than help it.
>>
>> Les -- I agree with you, however the problem as we see it is that
>> wicketstuff is not authoritative in any way. There are already multiple
>> shiro/ki/jsecurity projects on there, most of which are not maintained in
>> any way. It contains so many abandoned projects which scare off many
>> developers. And the versioning and build process is mostly out of our
>> control.
>
> Shouldn't the existing ki and jsecurity projects be deprecated and
> removed? One idea I would have is to move all the existing stuff into
> an 'attic' in the existing wicketstuff SVN repo and add your newest
> Shiro integration code to the wicket-shiro directory that already
> exists. Then you update the documentation to reflect this, and all
> pointers should go to your newest code base. I could help with this
> since I think I still have committer rights to that repo. We'd
> naturally have to run it by the community first of course, but if it
> has backing from the Shiro dev team, it would probably make sense to
> the Wicket dev team (I'm guessing).
>
> I think the Wicket and Wicket-stuff community would be fine with this
> approach - it doesn't make sense to maintain the old jsecurity/ki ones
> because they're not being maintained. It also removes the old garbage
> laying around, cleaning things up for the Wicket community, so there
> is no longer any feeling of fragmentation.
>
>> What Matt, Ryan and I have discussed is potentially contributing the new and
>> much cleaner integration to the shiro project itself, perhaps as a
>> shiro-wicket submodule. I see there is a shiro-quartz integration, so we're
>> hopeful this may be something the shiro devs would be open to. I'm convinced
>> that shiro-wicket would be seen as authoritative and most devs wouldn't
>> consider using the wicketstuff implementations. Is this a realistic goal, or
>> would the shiro team object to something like this?
>
> I think it is awesome that you guys are working to clean this up.
> This is great news!
>
> One of the struggles I have with this is one of maintenance - while I
> believe Wicket is a minor exception due to how many people use Shiro
> with Wicket, as the number of support modules increase, the higher the
> maintenance costs there are to the Shiro dev team. This is a real
> cost too - documentation, Jira issues, bugs, etc. It does take time.
>
> My other issue is one of scope. Shiro is a security framework, and as
> such, it usually sits at a lower level in the framework stack than UI
> frameworks. In other words, it makes sense for UI frameworks to know
> about and integrate with security, but the opposite doesn't make as
> much sense.
>
> Do you have any sense of whether or not the Wicket dev team is willing
> to support a wicket-shiro module in their own SVN repository instead
> of using wicket-stuff? Given that we're both ASF projects, and it can
> be modularized away from wicket core quite well, it seems like it
> would be ideal to be part of Wicket proper (instead of just
> WicketStuff).
>
> Since I wrote the initial (very rough) wicket-jsecurity mini project,
> I'd be very happy to help you guys in any way I can. Let me know if
> you think I should join the wicket dev list if you think this would be
> a good idea.
>
> As a final note, I struggle with this quite a bit - my first and
> foremost desire is to see people happy using Shiro in any application,
> and naturally integration with other frameworks only helps. It's just
> hard to juggle the time associated with that.
>
> What do you guys think about contacting the Wicket team?
>
> Best,
>
> Les
Re: shiro + wicket + backend
Posted by Tauren Mills <ta...@tauren.com>.
Les,
Thanks for your feedback. I'll respond inline below.
> Les -- I agree with you, however the problem as we see it is that
> > wicketstuff is not authoritative in any way. There are already multiple
> > shiro/ki/jsecurity projects on there, most of which are not maintained in
> > any way. It contains so many abandoned projects which scare off many
> > developers. And the versioning and build process is mostly out of our
> > control.
>
> Shouldn't the existing ki and jsecurity projects be deprecated and
> removed? One idea I would have is to move all the existing stuff into
> an 'attic' in the existing wicketstuff SVN repo and add your newest
> Shiro integration code to the wicket-shiro directory that already
> exists. Then you update the documentation to reflect this, and all
> pointers should go to your newest code base. I could help with this
> since I think I still have committer rights to that repo. We'd
> naturally have to run it by the community first of course, but if it
> has backing from the Shiro dev team, it would probably make sense to
> the Wicket dev team (I'm guessing).
>
Yes, deprecating and moving the existing packages to an attic would be a
good idea. I've not done that before and would be worried it would cause
someone's build to stop working. I suppose it would be fine if it was run by
the community first.
> I think the Wicket and Wicket-stuff community would be fine with this
> approach - it doesn't make sense to maintain the old jsecurity/ki ones
> because they're not being maintained. It also removes the old garbage
> laying around, cleaning things up for the Wicket community, so there
> is no longer any feeling of fragmentation.
>
> > What Matt, Ryan and I have discussed is potentially contributing the new
> and
> > much cleaner integration to the shiro project itself, perhaps as a
> > shiro-wicket submodule. I see there is a shiro-quartz integration, so
> we're
> > hopeful this may be something the shiro devs would be open to. I'm
> convinced
> > that shiro-wicket would be seen as authoritative and most devs wouldn't
> > consider using the wicketstuff implementations. Is this a realistic goal,
> or
> > would the shiro team object to something like this?
>
> I think it is awesome that you guys are working to clean this up.
> This is great news!
>
> One of the struggles I have with this is one of maintenance - while I
> believe Wicket is a minor exception due to how many people use Shiro
> with Wicket, as the number of support modules increase, the higher the
> maintenance costs there are to the Shiro dev team. This is a real
> cost too - documentation, Jira issues, bugs, etc. It does take time.
>
> My other issue is one of scope. Shiro is a security framework, and as
> such, it usually sits at a lower level in the framework stack than UI
> frameworks. In other words, it makes sense for UI frameworks to know
> about and integrate with security, but the opposite doesn't make as
> much sense.
>
I completely understand and respect your concerns. Personally, I'd like to
not have it part of wicketstuff any longer, as I've found wicketstuff's
versioning difficult to work with. I'd rather have more control over the
release schedule so that it can coincide with not only wicket, but also
shiro releases. However, there are certainly some advantages to just keeping
it at wicketstuff. And I'm not going to be the one doing the development,
so I'm fine leaving this choice to others. Basically, I see the following
four options:
1. Have it become part of Wicket
This would be the best solution, but I don't know if the wicket community
would accept another security module into wicket core. There is already
wicket-auth-roles, and I've gotten the sense that the devs feel it is
sufficient. Of course, it is certainly worth approaching them with the idea,
but the new version should be implemented with some demo apps for the devs
to review first.
2. Have it become part of Shiro
This route would give it exposure and credibility as well. However, you are
right -- a UI integration probably doesn't belong with a lower level
security framework. And maintenance would be a concern, however from what
I've seen of Matt's code, it would be very minor. By reusing all of the
Shiro annotations, there really isn't a lot to it.
3. Have it become a separate project (google code, github, etc.)
Personally, I like this approach, especially github because of how easy it
is to fork github projects and pull code from others. It also would give
full control over versioning, but would make it more difficult to provide
other features, such as availability from central maven repositories and
such. Exposure of the project could be enhanced if it was on github, but it
also wouldn't seem authoritative.
4. Keep it at wicketstuff
This would be the simplest and easiest approach. But we'd definitely want to
retire all of the old jsecurity/ki/shiro projects first and do everything we
can to make it known this is THE integration to use. Perhaps there is
something that can be done to have more control over versioning in a
wicketstuff project.
Do you have any sense of whether or not the Wicket dev team is willing
> to support a wicket-shiro module in their own SVN repository instead
> of using wicket-stuff? Given that we're both ASF projects, and it can
> be modularized away from wicket core quite well, it seems like it
> would be ideal to be part of Wicket proper (instead of just
> WicketStuff).
>
I have no definitive reason for this belief, but I expect the wicket devs
feel that wicket-auth-roles is sufficient to include with core and that
additional security framework integrations should be external. It is worth
discussing with them to make sure. It was for this reason that I asked you
and the Shiro community first.
> Since I wrote the initial (very rough) wicket-jsecurity mini project,
> I'd be very happy to help you guys in any way I can. Let me know if
> you think I should join the wicket dev list if you think this would be
> a good idea.
>
That would be great! I'm not going to be able to contribute much myself as
I'm swamped in real work. But I'm happy to chime in as time allows. Matt is
taking the lead on development and I'm sure he'd love input from you.
> As a final note, I struggle with this quite a bit - my first and
> foremost desire is to see people happy using Shiro in any application,
> and naturally integration with other frameworks only helps. It's just
> hard to juggle the time associated with that.
>
I understand. I do think making it easy for a framework to integrate shiro
would increase shiro adoption. But there is a point where you can't be
responsible to maintain all of these integrations.
Thanks again for your feedback,
Tauren
Re: shiro + wicket + backend
Posted by Les Hazlewood <lh...@apache.org>.
>> Since there are people using wicketstuff shiro integration already, I
>> think it'd be nice to have a new major version of the shiro parts if
>> the changes will be large. This way the existing community has an
>> obvious upgrade path without causing confusion. If it is perceived
>> that there is more than one wicket-shiro project, it would probably
>> frustrate and/or fragment the community rather than help it.
>
> Les -- I agree with you, however the problem as we see it is that
> wicketstuff is not authoritative in any way. There are already multiple
> shiro/ki/jsecurity projects on there, most of which are not maintained in
> any way. It contains so many abandoned projects which scare off many
> developers. And the versioning and build process is mostly out of our
> control.
Shouldn't the existing ki and jsecurity projects be deprecated and
removed? One idea I would have is to move all the existing stuff into
an 'attic' in the existing wicketstuff SVN repo and add your newest
Shiro integration code to the wicket-shiro directory that already
exists. Then you update the documentation to reflect this, and all
pointers should go to your newest code base. I could help with this
since I think I still have committer rights to that repo. We'd
naturally have to run it by the community first of course, but if it
has backing from the Shiro dev team, it would probably make sense to
the Wicket dev team (I'm guessing).
I think the Wicket and Wicket-stuff community would be fine with this
approach - it doesn't make sense to maintain the old jsecurity/ki ones
because they're not being maintained. It also removes the old garbage
laying around, cleaning things up for the Wicket community, so there
is no longer any feeling of fragmentation.
> What Matt, Ryan and I have discussed is potentially contributing the new and
> much cleaner integration to the shiro project itself, perhaps as a
> shiro-wicket submodule. I see there is a shiro-quartz integration, so we're
> hopeful this may be something the shiro devs would be open to. I'm convinced
> that shiro-wicket would be seen as authoritative and most devs wouldn't
> consider using the wicketstuff implementations. Is this a realistic goal, or
> would the shiro team object to something like this?
I think it is awesome that you guys are working to clean this up.
This is great news!
One of the struggles I have with this is one of maintenance - while I
believe Wicket is a minor exception due to how many people use Shiro
with Wicket, as the number of support modules increase, the higher the
maintenance costs there are to the Shiro dev team. This is a real
cost too - documentation, Jira issues, bugs, etc. It does take time.
My other issue is one of scope. Shiro is a security framework, and as
such, it usually sits at a lower level in the framework stack than UI
frameworks. In other words, it makes sense for UI frameworks to know
about and integrate with security, but the opposite doesn't make as
much sense.
Do you have any sense of whether or not the Wicket dev team is willing
to support a wicket-shiro module in their own SVN repository instead
of using wicket-stuff? Given that we're both ASF projects, and it can
be modularized away from wicket core quite well, it seems like it
would be ideal to be part of Wicket proper (instead of just
WicketStuff).
Since I wrote the initial (very rough) wicket-jsecurity mini project,
I'd be very happy to help you guys in any way I can. Let me know if
you think I should join the wicket dev list if you think this would be
a good idea.
As a final note, I struggle with this quite a bit - my first and
foremost desire is to see people happy using Shiro in any application,
and naturally integration with other frameworks only helps. It's just
hard to juggle the time associated with that.
What do you guys think about contacting the Wicket team?
Best,
Les
Re: shiro + wicket + backend
Posted by Tauren Mills <ta...@tauren.com>.
>
> > It is too soon to tell whether this is going to be an upgrade to
> wicketstuff wicket-shiro or, given the scope of the changes, perhaps a new
> project that supersedes it. Let me know if you have any thoughts or
> suggestions on where we should take this.
>
> Since there are people using wicketstuff shiro integration already, I
> think it'd be nice to have a new major version of the shiro parts if
> the changes will be large. This way the existing community has an
> obvious upgrade path without causing confusion. If it is perceived
> that there is more than one wicket-shiro project, it would probably
> frustrate and/or fragment the community rather than help it.
Les -- I agree with you, however the problem as we see it is that
wicketstuff is not authoritative in any way. There are already multiple
shiro/ki/jsecurity projects on there, most of which are not maintained in
any way. It contains so many abandoned projects which scare off many
developers. And the versioning and build process is mostly out of our
control.
What Matt, Ryan and I have discussed is potentially contributing the new and
much cleaner integration to the shiro project itself, perhaps as a
shiro-wicket submodule. I see there is a shiro-quartz integration, so we're
hopeful this may be something the shiro devs would be open to. I'm convinced
that shiro-wicket would be seen as authoritative and most devs wouldn't
consider using the wicketstuff implementations. Is this a realistic goal, or
would the shiro team object to something like this? Matt has been working on
an initial implementation which we will be reviewing and then make available
for shiro devs to review and comment.
As far as an upgrade path is concerned, that is certainly an issue to
consider. But the way the current wicket-shiro project is implemented could
do with significant changes. One of the main goals is to utilize Shiro's
annotations instead of the custom annotations in the project, which would
mean a backward compatible upgrade-path would be more difficult. I suppose
the custom annotations could just be deprecated wrappers for the shiro
annots. But in many ways it might be best to do something clean from scratch
and then update the wicket-shiro project with lots of references to the new
shiro-wicket project.
Fernando -- I too am a Wicket and Shiro user, but like you, I need to secure
additional layers past the UI. My application has a RESTful API built with
Jersey and Jackson. I'm also using Spring and tend to agree with Kalle that
integrating Spring is worth doing. My suggestion would be to see about
adding Spring into the mix and let it handle a lot of the AOP aspects for
you.
Tauren
Re: shiro + wicket + backend
Posted by Les Hazlewood <lh...@apache.org>.
> Yes, I am talking with the current maintainers of the wicketstuff wicket-shiro project to make some big improvements to it. Namely I am looking to leverage Shiro's annotations rather than the custom annotations that wicket-shiro currently uses.
Ah - nice. That should be a little easier to maintain.
> It is too soon to tell whether this is going to be an upgrade to wicketstuff wicket-shiro or, given the scope of the changes, perhaps a new project that supersedes it. Let me know if you have any thoughts or suggestions on where we should take this.
Since there are people using wicketstuff shiro integration already, I
think it'd be nice to have a new major version of the shiro parts if
the changes will be large. This way the existing community has an
obvious upgrade path without causing confusion. If it is perceived
that there is more than one wicket-shiro project, it would probably
frustrate and/or fragment the community rather than help it.
Just my .02,
Cheers,
Les
Re: shiro + wicket + backend
Posted by mbrictson <ma...@55minutes.com>.
Hi Les,
Yes, I am talking with the current maintainers of the wicketstuff wicket-shiro project to make some big improvements to it. Namely I am looking to leverage Shiro's annotations rather than the custom annotations that wicket-shiro currently uses.
It is too soon to tell whether this is going to be an upgrade to wicketstuff wicket-shiro or, given the scope of the changes, perhaps a new project that supersedes it. Let me know if you have any thoughts or suggestions on where we should take this.
Thanks.
--
Matt
On Nov 22, 2010, at 11:33 AM, Les Hazlewood-2 [via Shiro User] wrote:
> Hi Matt,
>
> The Wicketstuff project has Shiro integration efforts:
>
> http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-shiro
>
> Are you involved with that?
>
> Cheers,
>
> --
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and Training:
> http://www.katasoft.com
>
> On Mon, Nov 22, 2010 at 10:28 AM, mbrictson <[hidden email]> wrote:
>
> >
> > On Nov 22, 2010, at 5:20 AM, Fernando Wermus-3 [via Shiro User] wrote:
> >
> >> I would like to ask you about if you have used some kind of annotation for wicket-shiro. I am extending each component and overriding isVisible and isEnabled. I mean I am extending the components in the case of bussiness level authorization.
> >
> > I'm actually working on a library right now that will allow you to use Shiro annotations directly on Wicket pages and components. I'll be sure to post to this list when it is ready.
> >
> > In the meantime, if you have a wishlist for what you'd like to see in a Shiro-Wicket integration library, please feel free to email me directly.
> >
> > --
> > Matt
> >
> >
> > --
> > View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5763734.html
> > Sent from the Shiro User mailing list archive at Nabble.com.
>
>
> View message @ http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5764006.html
> To unsubscribe from shiro + wicket + backend, click here.
--
View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5764062.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: shiro + wicket + backend
Posted by Les Hazlewood <lh...@apache.org>.
Hi Matt,
The Wicketstuff project has Shiro integration efforts:
http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-shiro
Are you involved with that?
Cheers,
--
Les Hazlewood
Founder, Katasoft, Inc.
Application Security Products & Professional Apache Shiro Support and Training:
http://www.katasoft.com
On Mon, Nov 22, 2010 at 10:28 AM, mbrictson <ma...@55minutes.com> wrote:
>
> On Nov 22, 2010, at 5:20 AM, Fernando Wermus-3 [via Shiro User] wrote:
>
>> I would like to ask you about if you have used some kind of annotation for wicket-shiro. I am extending each component and overriding isVisible and isEnabled. I mean I am extending the components in the case of bussiness level authorization.
>
> I'm actually working on a library right now that will allow you to use Shiro annotations directly on Wicket pages and components. I'll be sure to post to this list when it is ready.
>
> In the meantime, if you have a wishlist for what you'd like to see in a Shiro-Wicket integration library, please feel free to email me directly.
>
> --
> Matt
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5763734.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Re: shiro + wicket + backend
Posted by mbrictson <ma...@55minutes.com>.
On Nov 22, 2010, at 5:20 AM, Fernando Wermus-3 [via Shiro User] wrote:
> I would like to ask you about if you have used some kind of annotation for wicket-shiro. I am extending each component and overriding isVisible and isEnabled. I mean I am extending the components in the case of bussiness level authorization.
I'm actually working on a library right now that will allow you to use Shiro annotations directly on Wicket pages and components. I'll be sure to post to this list when it is ready.
In the meantime, if you have a wishlist for what you'd like to see in a Shiro-Wicket integration library, please feel free to email me directly.
--
Matt
--
View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5763734.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: shiro + wicket + backend
Posted by Fernando Wermus <fe...@gmail.com>.
I would like to ask you about if you have used some kind of annotation for
wicket-shiro. I am extending each component and overriding isVisible and
isEnabled. I mean I am extending the components in the case of bussiness
level authorization.
thanks
On Sun, Nov 21, 2010 at 11:46 PM, mbrictson <ma...@55minutes.com> wrote:
>
>
> Fernando Wermus-3 wrote:
> >
> > I am using shiro successfully with wicket. But I need to develop
> > authorization for services in the backend.
> >
>
> Could you elaborate on your requirements a bit more? As a fellow Wicket
> developer who is also using Shiro, I would be interested in hearing how you
> have your application set up, and how you are dividing the security
> concerns
> between Wicket and backend.
>
> In my experience it has usually been easier to deal with authorization at
> the Wicket layer, because the UIs I build dictate that components need to
> be
> shown or hidden conditionally based on security concerns (e.g. "delete"
> link
> should be shown for admins, but not for other users). The nice thing about
> Wicket is that if a component is hidden, the action that component performs
> is inherently secured. There is no way for a user to invoke the onClick()
> code (i.e. perform the delete action) if the component is not being shown.
> So authorization at the Wicket layer goes a long way.
>
> I always hesitate moving authorization to the service layer, because there
> will inevitably be repetition of logic: the UI visibility checks at the
> Wicket layer will still be needed, plus there will be redundant service
> layer checks (e.g. securing the delete() method).
>
> For what it's worth, I agree that if you are going with an AOP solution
> with
> Wicket, Spring is your best bet. But before you overhaul your app to
> integrate Spring, I would first verify that AOP-style authorization of your
> service layer is really needed. In your backend, you can use assertions
> like
> SecurityUtils.getSubject().checkPermission(). That would not require
> Spring.
> You only need Spring if you want to use Shiro annotations or another AOP
> approach.
>
> --
> Matt
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5761393.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
--
Fernando Wermus.
www.linkedin.com/in/fernandowermus
Re: shiro + wicket + backend
Posted by mbrictson <ma...@55minutes.com>.
On Nov 22, 2010, at 4:26 AM, Fernando Wermus-3 [via Shiro User] wrote:
> The reason why we need authorization at back end level is because we have mixed wicket with flex and flex connects to backend straight forward.
Ah, that makes perfect sense. Thanks for clarifying.
--
Matt
--
View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5763723.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: shiro + wicket + backend
Posted by Fernando Wermus <fe...@gmail.com>.
Thanks for your replied. It was very useful.
The reason why we need authorization at back end level is because we have
mixed wicket with flex and flex connects to backend straight forward. Then
authorization at wicket or front end level is not enough.
thanks for all your thoughts about this!
On Sun, Nov 21, 2010 at 11:46 PM, mbrictson <ma...@55minutes.com> wrote:
>
>
> Fernando Wermus-3 wrote:
> >
> > I am using shiro successfully with wicket. But I need to develop
> > authorization for services in the backend.
> >
>
> Could you elaborate on your requirements a bit more? As a fellow Wicket
> developer who is also using Shiro, I would be interested in hearing how you
> have your application set up, and how you are dividing the security
> concerns
> between Wicket and backend.
>
> In my experience it has usually been easier to deal with authorization at
> the Wicket layer, because the UIs I build dictate that components need to
> be
> shown or hidden conditionally based on security concerns (e.g. "delete"
> link
> should be shown for admins, but not for other users). The nice thing about
> Wicket is that if a component is hidden, the action that component performs
> is inherently secured. There is no way for a user to invoke the onClick()
> code (i.e. perform the delete action) if the component is not being shown.
> So authorization at the Wicket layer goes a long way.
>
> I always hesitate moving authorization to the service layer, because there
> will inevitably be repetition of logic: the UI visibility checks at the
> Wicket layer will still be needed, plus there will be redundant service
> layer checks (e.g. securing the delete() method).
>
> For what it's worth, I agree that if you are going with an AOP solution
> with
> Wicket, Spring is your best bet. But before you overhaul your app to
> integrate Spring, I would first verify that AOP-style authorization of your
> service layer is really needed. In your backend, you can use assertions
> like
> SecurityUtils.getSubject().checkPermission(). That would not require
> Spring.
> You only need Spring if you want to use Shiro annotations or another AOP
> approach.
>
> --
> Matt
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5761393.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
--
Fernando Wermus.
www.linkedin.com/in/fernandowermus
Re: shiro + wicket + backend
Posted by mbrictson <ma...@55minutes.com>.
Fernando Wermus-3 wrote:
>
> I am using shiro successfully with wicket. But I need to develop
> authorization for services in the backend.
>
Could you elaborate on your requirements a bit more? As a fellow Wicket
developer who is also using Shiro, I would be interested in hearing how you
have your application set up, and how you are dividing the security concerns
between Wicket and backend.
In my experience it has usually been easier to deal with authorization at
the Wicket layer, because the UIs I build dictate that components need to be
shown or hidden conditionally based on security concerns (e.g. "delete" link
should be shown for admins, but not for other users). The nice thing about
Wicket is that if a component is hidden, the action that component performs
is inherently secured. There is no way for a user to invoke the onClick()
code (i.e. perform the delete action) if the component is not being shown.
So authorization at the Wicket layer goes a long way.
I always hesitate moving authorization to the service layer, because there
will inevitably be repetition of logic: the UI visibility checks at the
Wicket layer will still be needed, plus there will be redundant service
layer checks (e.g. securing the delete() method).
For what it's worth, I agree that if you are going with an AOP solution with
Wicket, Spring is your best bet. But before you overhaul your app to
integrate Spring, I would first verify that AOP-style authorization of your
service layer is really needed. In your backend, you can use assertions like
SecurityUtils.getSubject().checkPermission(). That would not require Spring.
You only need Spring if you want to use Shiro annotations or another AOP
approach.
--
Matt
--
View this message in context: http://shiro-user.582556.n2.nabble.com/shiro-wicket-backend-tp5760310p5761393.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: shiro + wicket + backend
Posted by Kalle Korhonen <ka...@gmail.com>.
Though it comes with some baggage, integrating Spring would probably
still be the path of least resistance for you since its tried and
widely used. It's not your only option however; you could also use
aspectj support directly. In terms of lines of code, the effort
required to write an aspect for securing some service calls is
minimal, but learning AOP takes some time if you never used it before.
Finally, and I don't know if you want to explore that route, but
somebody just wrote a wicket/tapestry-ioc integration module
(https://github.com/criedel/WicketTap5IOC) and tapestry-security
(http://tynamo.org/tapestry-security+guide) has built-in support for
securing services via annotations.
Kalle
On Sun, Nov 21, 2010 at 7:21 AM, Fernando Wermus
<fe...@gmail.com> wrote:
> Hi all,
> I am using shiro successfully with wicket. But I need to develop
> authorization for services in the backend. I am thinking of using some kind
> of interceptor, which authorizes the called. We don't use spring and we need
> to find a way to develop it with the minimun effort. Is there any solution
> that not take into account spring for security and has its all benefits? Or
> should we integrate our app with spring?
> thanks in advance
>
> --
> Fernando Wermus.
>
> www.linkedin.com/in/fernandowermus
>