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]
