You don't use implies yourself. the framework will use it for you.
all you have to do is implement the method.
For example our implies looks like this (modified for readability)
public boolean implies(Subject subject)
{
if (subject == null)
return false;
String myName = getName();
for (Principal principal : (Set<Principal>)
subject.getPrincipals())
{
//each RechtenSet as our principals are called has a list of other
principals it implies and a list of principals that imply this one
if (myName.equals(principal.getName())
|| (principal instanceof RechtenSet &&
((RechtenSet)
principal).implies(this)))
{
return true;
}
}
return false;
}
//check if another principal is implied
public boolean implies(RechtenSet rechtenSet)
{
//because the list of implied principals is searched recursively and
may contain loops we use a set to store principals we have already
visited
return internalImplies(rechtenSet, new HashSet<RechtenSet>());
}
private boolean internalImplies(RechtenSet rechtenSet, Set<RechtenSet>
tried)
{
//implies is the list of principals this principal implies
if (rechtenSet == null || implies == null || implies.isEmpty())
{
tried.add(this);
return false;
}
if (!tried.add(this))
return false; // we already tried this principal
for (RechtenSet set : implies)
{
if (set.getName().equals(rechtenSet.getName()))
return true;
if (set.internalImplies(rechtenSet, tried))
return true;
}
return false;
}
We store our principals in a database so we can preserve and easily
modify the imply lists. Not to mention attach them easily to a user :)
Maurice
On Feb 20, 2008 1:40 AM, Warren <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
