deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shane Bryzak (Commented) (JIRA)" <>
Subject [jira] [Commented] (DELTASPIKE-64) review and discuss @Secured
Date Tue, 31 Jan 2012 11:56:10 GMT


Shane Bryzak commented on DELTASPIKE-64:

In Seam Security we have a system of typesafe security annotations.  Essentially, it's up
to the developer to create the annotations required for the authorization checks in their
application.  The security binding annotations are annotated with @SecurityBindingType, here's
an example:

@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Admin {

The annotation may declare member variables also which are taken into account for the authorization
check, unless the member is annotated @Nonbinding.

Authorizer methods are used to determine whether a user has sufficient privileges to invoke
a secured method.  The @Secures annotation is used in combination with the security binding
type annotation to declare the authorizer method, eg:

    public @Secures @Admin boolean isAdmin(Identity identity) {
        return identity.hasRole("admin", "USERS", "GROUP");

This allows combinations of security binding types to be declared on a single method or class,
and also has the advantage of allowing the user to declare all of their security "business
logic" in a single bean.  Once the security binding type annotation and the authorizer method
is declared, it is then a simple matter of applying the annotation:

    public void doSomethingRestricted() {"doSomethingRestricted() invoked");
> review and discuss @Secured
> ---------------------------
>                 Key: DELTASPIKE-64
>                 URL:
>             Project: DeltaSpike
>          Issue Type: Sub-task
>          Components: Security-Module
>    Affects Versions: 0.1
>            Reporter: Gerhard Petracek
>            Assignee: Gerhard Petracek
>             Fix For: 0.2
> this feature is listed at
and part of myfaces codi-core.
> @Secured is a simple cdi interceptor annotation which allows to filter method calls to
cdi beans based on custom rules.
> it's possible to specify 1-n custom implementations of AccessDecisionVoter. those voters
get invoked before the call is forwarded to the target method (a voter is a cdi bean which
gets resolved by its concrete type). an implementation of AccessDecisionVoter can access the
InvocationContext to get further details about the target method to trigger the corresponding
evaluation. as a result voters return a set of violations (SecurityViolation). if there is
no violation, the target-method gets executed. if there is at least one violation, an AccessDeniedException
will be thrown.
> in addition an AccessDecisionVoterContext is needed to detect if there is an ongoing
security check (e.g. it's possible to use it in a custom scope to avoid that a security check
postpones the expiration).
> (in myfaces codi it's also used to secure views via view-configs, however, we will exclude
this part for now.)
> users can use those simple and generic apis to implement their own access control and
it will get used by other deltaspike modules automatically (if they use the security-api).
> (in an AccessDecisionVoter it's possible to integrate 3rd party security-frameworks.)
> usage of @Secured:
> //...
> @Secured({MyAccessDecisionVoter1.class, MyAccessDecisionVoter2.class})
> public class SecuredBean
> {
>     //...
> }

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message