-
1. Re: Permission-based authorization in Seam Faces
shane.bryzak Apr 6, 2011 5:27 PM (in response to fabriciolemos)You can already use identity.hasPermission() in your typesafe authorization checks. It's not limited to role/group restrictions.
-
2. Re: Permission-based authorization in Seam Faces
fabriciolemos Apr 6, 2011 6:50 PM (in response to fabriciolemos)But in the typesafe way I need to have an annotation and a method check for each kind of restriction, right?
So in a Permission-based authorization I would have to have:
public @Secures @Permission1 boolean userHasPermission1(Identity identity) { return identity.hasPermission("permission1"); } public @Secures @Permission2 boolean userHasPermission2(Identity identity) { return identity.hasPermission("permission2"); } and so on...
As the number of permissions are a lot greater than roles and groups, this becomes really cumbersome.
Wouldn't
@Restrict("{identity.hasPermission()}") or <s:restrictView require="{identity.hasPermission()}"/>
be more appropriate for this scenario?
-
3. Re: Permission-based authorization in Seam Faces
shane.bryzak Apr 6, 2011 6:55 PM (in response to fabriciolemos)You could just implement this yourself. Create a @Restrict annotation that's annotated with @SecurityBindingType, and give it a @Nonbinding member to hold the EL expression.
-
4. Re: Permission-based authorization in Seam Faces
fabriciolemos Apr 7, 2011 9:46 AM (in response to fabriciolemos)Any hints on how can I access the annotation member value in the authorizer method?
-
5. Re: Permission-based authorization in Seam Faces
shane.bryzak Apr 7, 2011 5:07 PM (in response to fabriciolemos)Hmm, very good point, it seems that I overlooked this. Would you be able to raise an issue in JIRA? [1] That way I can make it a priority to fix it.
-
6. Re: Permission-based authorization in Seam Faces
fabriciolemos Apr 8, 2011 11:18 AM (in response to fabriciolemos)I created https://issues.jboss.org/browse/SEAMSECURITY-57
In this case of an EL based authorization I think that for Seam Faces would be more appropriate to use
<s:restrictView require="#{xxx}"/>
I do not see any advantage of adding an indirection through @ViewConfigAlso https://issues.jboss.org/browse/SEAMFACES-79 is already the most voted issue
-
7. Re: Permission-based authorization in Seam Faces
fabriciolemos Jun 21, 2011 4:47 PM (in response to fabriciolemos)Sorry to insist, but is this issue planned for the next version of Seam Security?
As for now it´s really painfull having to change my source code, recompile and redeploy my app every time the rights for certain resources changes.
-
8. Re: Permission-based authorization in Seam Faces
lightguard Jun 21, 2011 5:52 PM (in response to fabriciolemos)Are you looking for something to restrict JSF views or something else? If that's the case (the JSF views) take a look at the ViewMetaData stuff in Seam Faces, don't recall if EL was supported or not though. If it isn't it would be a good issue to move over to Seam Faces.
-
9. Re: Permission-based authorization in Seam Faces
ssachtleben.ssachtleben.gmail.com Jun 21, 2011 6:03 PM (in response to fabriciolemos)I'm using currently this:
<s:viewAction action="#{mybean.validate}"/>
And if the conditions doesnt meet you can redirect by return the new view id:
return "pretty:myNewId";
You could even add a faces message before the return.
-
10. Re: Permission-based authorization in Seam Faces
lightguard Jun 22, 2011 3:17 AM (in response to fabriciolemos)No, sorry it doesn't look like we have this in Seam 3 just yet. However, it doesn't look like it would be too difficult to implement. Look at http://docs.jboss.org/seam/3/3.0.0.Final/reference/en-US/html/security-authorization.html#d0e6021 and http://docs.jboss.org/seam/3/faces/3.0.2.Final/reference/en-US/html/viewconfig.html for information about how to create the security bindings and apply them to the view config.
My suggestion, just off the top of my head, is to create a non-binding attribute on the annotation that will hold the EL. This will be used as metadata about the constraint and evaluated later. In the method that evaluates the security constraint inject the ELContext, or the FacesContext and pull it from there, evaluate the EL and use the result of that. This all hinges on being able to get the security binding annotation instance. If you can't this won't work, and it really should be filed as an RFE in that case.
-
11. Re: Permission-based authorization in Seam Faces
fabriciolemos Jun 22, 2011 4:29 PM (in response to fabriciolemos)I´m looking for restricting JSF views. Sebastian´s suggestion seems nice while SEAMFACES-79 is not implemented. I will try it out, thanks
Jason, your suggestions seems like the same from Shane a few posts above, which I´m not able to implement as I don´t know how to access, in my authorization method, the non-binding attribute value that holds the EL.
-
12. Re: Permission-based authorization in Seam Faces
fabriciolemos Jan 4, 2012 8:28 AM (in response to fabriciolemos)Since s:viewAction is broken for post requests and SEAMFACES-79 will probably never be implemented (created almost a year ago), do you have any guidance to avoid to hard code the permissions for groups and roles?
-
13. Re: Permission-based authorization in Seam Faces
lightguard Jan 4, 2012 4:13 PM (in response to fabriciolemos)Fabricio, sorry, not sure atm. We'll have to take a closer look. We're pretty much done with 3.1.0.Final so we'll be looking at issues to go into 3.2.0.
-
14. Re: Permission-based authorization in Seam Faces
aogier Apr 3, 2012 12:14 PM (in response to lightguard)And now that 3.1.0.Final is out, is there a planification for this use case ?
We need it also... and what we do instead is a little ugly : in the called action method, we have a specific call to our RightManager.checkRight("group", "role")... it would be better with a @CheckRight("group", "role") on the action method, which would be handled by our own @Secures @CheckRight method, if and only if we could have the secured annotation (@CheckRight) passed as a parameter for that check method...
In other words, I think the @Nonbinding annotation is a bit useless as this... isn't it ?