[ 
http://www.stripesframework.org/jira/browse/STS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11193#action_11193
 ] 

Andrew Jaquith commented on STS-495:
------------------------------------

This provides an alternative to a container Role check. This type of security 
check is looks for possession of a Java 2 platform security permission. For 
example, you might have the need to check against the global Java security 
policy to see if the user possesses the correct Permission.

Typically, security policies look like this:

grant principal "Gregg" {
    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*", 
"modify";
    permission java.io.FilePermission "/tmp", "read";
};

In the case I'm suggesting, a security interceptor could look up the required 
Permission via the annotation, and pass it to an access-checking routine. 

For example, the snippet below will check the JVM security policy to see if the 
user has been granted the Permission by the security policy. (More correctly, 
it checks to see if the Permission has been granted to one of the Principals 
that are part of a Subject that represents the user). We assume that the 
Subject was obtained some other way, perhaps as part of an application-specific 
security system:

        Boolean allowed = (Boolean)Subject.doAsPrivileged( subject, new 
PrivilegedAction() {
            public Object run()
            {
                try
                {
                    // Check the JVM-wide security policy
                    AccessController.checkPermission( permission );
                    return Boolean.TRUE;
                }
                catch( AccessControlException e )
                {
                    // JVM policy denied the permission
                }
                return Boolean.FALSE;
            }
        }, null );

So, to sum up, this @EventPermission annotation allows specification of J2SE 
platform Permissions rather than container Roles. This isn't as far-fetched as 
it sounds: the JACC specification, for example, requires containers to allow 
callers to express container permissions via the J2SE policy.



> EventPermission annotation for Stripes events methods
> -----------------------------------------------------
>
>                 Key: STS-495
>                 URL: http://www.stripesframework.org/jira/browse/STS-495
>             Project: Stripes
>          Issue Type: New Feature
>          Components: ActionBean Dispatching
>    Affects Versions: Release 1.4.3
>         Environment: All
>            Reporter: Andrew Jaquith
>            Assignee: Tim Fennell
>         Attachments: EventPermission.java, EventPermissionInfo.java, 
> WikiInterceptor.java
>
>
> Hi Tim and all -
> We're planning to use Stripes in an a future release of Apache JSPWiki. While 
> doing the integration, I wrote an a method annotation and supporting classes 
> that turned out to be quite generic, and could be quite useful for all 
> Stripes users. So I thought I'd write it up in the hopes of getting it into 
> Stripes 1.5. The idea is pretty simple: use the method annotation 
> @EventPermission to identify what Java Permissions would be needed to 
> successfully execute an event.
> Here's how it works. Suppose we have an Actionbean whose default event is the 
> "view()" method, but we want to make sure the caller possesses a particular 
> Permission. Here's the method signature:
>    @DefaultHandler
>    @HandlesEvent("view")
>    @EventPermission(
>       permissionClass=PagePermission.class,
>       target="${page.qualifiedName}",
>       actions=PagePermission.VIEW_ACTION)
>    public Resolution view() { ... }
> Note the @EventPermission annotation. It defines the Permission class and its 
> target and actions. The "permissionClass" attribute tells use that the 
> Permission class this method needs is "PagePermission" (a custom Permission 
> class). Note also the JSTL-style syntax in the target and actions attributes 
> -- these allow JSTL-access to bean properties for the instantiated 
> ViewActionBean. In this case, "${page}" is the bean attribute that returns 
> the value of this ViewActionBean's getPage() method. The nested syntax 
> "${page.qualifiedName}" is equivalent to getPage().getQualifiedName(). Neat, 
> huh?
> An annotation like this would collaborate with a security interceptor that 
> fires during the binding/validation stage:
> @Intercepts( { LifecycleStage.BindingAndValidation })
> public class WikiInterceptor implements Interceptor
>     public Resolution intercept(ExecutionContext context) throws Exception {
> ...
>         // Does the event handler have a required permission?
>         boolean allowed = true;
>         EventPermissionInfo permInfo = beanContext.getPermissionInfo(handler);
>         if ( permInfo != null )
>         {
>             Permission requiredPermission = 
> permInfo.getPermission(actionBean);
>             if ( requiredPermission != null )
>             {
>                 // security checking code goes here...
>             }
>         }
>         // If not allowed, redirect to login page with all parameters intact;
>         // otherwise proceed
>         if (!allowed)
>         {
>             r = new RedirectResolution(LoginActionBean.class);
>             ((RedirectResolution) r).includeRequestParameters(true);
>             return r;
>         }
>     }
> I have attached several sample source files. I have not "cleansed" them yet 
> -- so if they are of interest to you, I'll do that.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to