Where am I using Principal.implies(Subject subject); and how? I add the Principals to my Subject when I authenticate my user, is it here or am I setting this up in my app or in my policy file? It is getting clearer how things are working. I have always created my own security implementation, I have not had any experience with anybody else's.
> -----Original Message----- > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 19, 2008 2:27 PM > To: [EMAIL PROTECTED] > Subject: Re: Wicket-security wish list > > > On Feb 19, 2008 10:39 PM, Warren <[EMAIL PROTECTED]> wrote: > > Maurice, > > > > Session.error() is how I ended up solving my problem. But, I > formatted the > > message in my session and then ended up calling error(...), that way > > SwarmStrategy was just returning the denied Principals. I did > not get as far > > as placing the message in a Properties file. I was not sure how to > > accommodate multiple denied Principals. As far as the multiple > principals in > > my app, I simply formatted my message like this: > > > > Users in User Group XXX do not have Access to "Access Denied > Principal 1" > > and "Access Denied Principal 2" ... > > Ok good to know. > > > > > I know that this can get a little verbose, but I am trying to set up my > > policy file so that any one permission does not end up in too > many different > > Principals. This will probably be an issue when using the > "inherit" action > > though. > > Using the inherit action has noting to do with how many principals are > linked to a permission. > Currently inherit action is primarily intended for the following > situation: > A page has both secure and normal components, the secure components > allow for editing of the modelobject of the page (for the sake of this > example i will assume they are textfields). > All components should always be visible but only editable if > sufficient permissions are granted. The policy would look something > like this: > grant principal "foo.read" > { > permission ${ComponentPermission} "org.MyPage", "inherit, render"; > // to allow all components to be rendered > //using only render would require separate render permissions for each > component like so > //permission ${ComponentPermission} "org.MyPage:secureTextField1", > "render"; //etc for each secure component > > //assuming we have 1 or more links pointing to our page we also need > the following permission > permission ${ComponentPermission} "org.MyPage", "enable"; > //note the absence of the inherit permission compared to the next > principal > //by not using inherit the enable action is only granted to the page > itself not to any of the secure components it contains > }; > grant principal "foo.write" > { > permission ${ComponentPermission} "org.MyPage", "inherit, enable"; > //to allow the user to use all the secure textfields on the page > } > > If you want to prevent permissions to be linked to to many principals > you should use Principal.implies(Subject subject); > The above example works without this implies because the "inherit, > enable" actions already imply the "inherit, render" actions for the > same component(s). > In the following example however that is not going to work: > Say we have a display page and an edit page, in this example it does > not matter if the edit page contains secure components or not because > the entire page is only visible if you have sufficient permissions. > grant principal "foo.read" > { > permission ${ComponentPermission} "org.MyDisplayPage", "inherit, render"; > // still using inherit here out of habbit > > //assuming we have 1 or more links pointing to our display page we > also need the following permission > permission ${ComponentPermission} "org.MyDisplayPage", "enable"; > }; > grant principal "foo.write" > { > permission ${ComponentPermission} "org.MyEditPage", "inherit, render"; > //assuming we only have normal textfields and stuff on the page > > //the display page probably has a securepagelink pointing to our edit > page so we need to grant permission for that > permission ${ComponentPermission} "org.MyRenderPage", "enable"; > } > We could solve the above example 2 ways: > - the subject would need to have both foo.read and foo.write for him > to access the edit page through the edit button on the display page > -or we use principal.implies to specify that if the user only has > foo.write we can safely assume he also (should) have foo.read > > What happens in swarm is this: > 1 user tries to go to display page > 2 check render permission for display page > 3 detects none of the principals from the subject have this permission > (remember or subject only has foo.write) > 4 check each of the principals that contain the permission (as > specified in the hive) if they imply the subject > 5 foo.read principal detects the subject has the foo.write principal > and signals that the permission is granted > 6 wicket renders page > > The way we handle principal.implies in our application is by letting > our principal have a doubly linked list of both principals it implies > and principals it is implied by, the check to see if the subject has > another principal it is implied by is then easy. > > phew, this mail certainly got a lot longer than i intended and might > haven gotten a bit off-topic but i got the feeling some things were > not quite crystal clear :) > > Maurice > > > > > > > -----Original Message----- > > > From: Maurice Marrink [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, February 19, 2008 1:27 PM > > > To: [email protected] > > > Subject: Re: Wicket-security wish list > > > > > > > > > Thanks, > > > > > > Glad i could help. > > > > > > I like the idea of custom error messages but i doubt i will make them > > > configurable in the policy file, mainly because i would like to follow > > > the jaas policy format as close as possible and because a permission > > > can be part of multiple principals: what would we do then display the > > > message from each principal? > > > I am thinking more in the lines of using Session.error() to display > > > localized messages in the properties files currently used by wicket. > > > But I will have to think about this. Thanks for the suggestion. > > > I have created a jira issue so i won't forget it :) > > > http://wicketstuff.org/jira/browse/WSSWARM-6 > > > > > > Maurice > > > > > > On Feb 19, 2008 8:47 PM, Warren <[EMAIL PROTECTED]> wrote: > > > > Maurice, > > > > > > > > I was thinking about this "Access Denied" message problem I > have been > > > > working on and thought up some features that might be > useful in future > > > > releases. It would be nice to be able to configure "Access > > > Denied" messages > > > > directly into the hive like this: > > > > > > > > grant principal > > > com.scanman.security.authorization.ScanManPrincipal "ScanMan > > > > Receiving" "Principal Access Denied Message Here" > > > > { > > > > permission ${ComponentPermission} "${RecvMenu}", > > > "inherit, render, enable", > > > > "Permission Access Denied Message Here"; > > > > }; > > > > grant principal > > > com.scanman.security.authorization.ScanManPrincipal "ScanMan > > > > Ordering" "Principal Access Denied Message Here" > > > > { > > > > permission ${ComponentPermission} "${OrderMenu}", > > > "inherit, render, > > > > enable", "Permission Access Denied Message Here"; > > > > }; > > > > > > > > I believe you are following some kind of standard for how > the hive is > > > > set-up, so I am not sure this would work. But anyway, you could > > > then set-up > > > > the configuration of how these messages were used in the > > > > SwarmWebApplication. For Example, put them into the error > queue, or take > > > > advantage of message resources, message keys and localization > > > and so on. I > > > > ended up putting these messages into the error queue from > > > MySwarmStrategy > > > > and it works great. > > > > > > > > I can't imagine that a feature like this would not be of some > > > value to other > > > > users. My app has a lot of different levels of security and > > > permissions that > > > > the Administrative user can configure within a separate "Point > > > of Sale" app. > > > > Messages of this sort are valuable to a user so that > security levels and > > > > permissions can be tweaked to best suit a companies > policies. A simple > > > > "Access Denied" message gives little clue as to why access > was denied. > > > > > > > > That's my two cents. Thanks for all the help you have given me. > > > Your project > > > > surely deserves a lot of credit. > > > > > > > > Thanks, > > > > > > > > Warren Bell > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
