Return-Path: X-Original-To: apmail-deltaspike-commits-archive@www.apache.org Delivered-To: apmail-deltaspike-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C7419186DB for ; Tue, 12 May 2015 18:37:25 +0000 (UTC) Received: (qmail 41048 invoked by uid 500); 12 May 2015 18:37:25 -0000 Delivered-To: apmail-deltaspike-commits-archive@deltaspike.apache.org Received: (qmail 41009 invoked by uid 500); 12 May 2015 18:37:25 -0000 Mailing-List: contact commits-help@deltaspike.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@deltaspike.apache.org Delivered-To: mailing list commits@deltaspike.apache.org Received: (qmail 40994 invoked by uid 99); 12 May 2015 18:37:25 -0000 Received: from eris.apache.org (HELO hades.apache.org) (140.211.11.105) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 May 2015 18:37:25 +0000 Received: from hades.apache.org (localhost [127.0.0.1]) by hades.apache.org (ASF Mail Server at hades.apache.org) with ESMTP id 7F3CCAC1150 for ; Tue, 12 May 2015 18:37:25 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r951069 [2/2] - in /websites/staging/deltaspike/trunk/content: ./ documentation/ Date: Tue, 12 May 2015 18:37:25 -0000 To: commits@deltaspike.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20150512183725.7F3CCAC1150@hades.apache.org> Modified: websites/staging/deltaspike/trunk/content/documentation/security.html ============================================================================== --- websites/staging/deltaspike/trunk/content/documentation/security.html (original) +++ websites/staging/deltaspike/trunk/content/documentation/security.html Tue May 12 18:37:24 2015 @@ -276,12 +276,27 @@ table.CodeRay td.code>pre{padding:0}

Overview

-

The Security module provides intercept and security checking on method calls. This module also enables integration of third-party security frameworks and custom security concepts.

+

The Security module provides APIs for authorization of method invocations.

+
+
+

There are two different APIs provided for two different approaches — one simple interceptor-style API and another for more complex scenarios.

+
+
+
    +
  • +

    Simple interceptor-style API: the method that is to be secured is loosely coupled to a predicate method +(called authorizer method) which decides whether the secured method invocation should proceed. Similarly to CDI +interceptors, the secured method and the authorizer are tied together using a binding annotation — @SecurityBindingType in this case.

    +
  • +
  • +

    Advanced API: this API offers fine-grained control over the authorization process. Multiple independent voters can participate in making the authorization decision and possibly return security violations and thus prevent the method invocation. The voters share a common context. This API is suitable for integration with third-party security frameworks. Also, this API can be used to secure JSF view access when using the DeltaSpike JSF module.

    +
  • +
-

Configure Your Projects

+

Project Setup

The configuration information provided here is for Maven-based projects and it assumes that you have already declared the DeltaSpike version and DeltaSpike Core module for your projects, as detailed in Configure DeltaSpike in Your Projects. For Maven-independent projects, see Configure DeltaSpike in Maven-independent Projects.

@@ -310,7 +325,7 @@ table.CodeRay td.code>pre{padding:0}
-

2. Enable the Security Interceptor

+

2. Enable the SecurityInterceptor

For CDI 1.0 (or DeltaSpike v1.1.0 and earlier together with CDI 1.1+), you must enable the security interceptor in the project beans.xml file:

@@ -328,51 +343,44 @@ table.CodeRay td.code>pre{padding:0}
-

Use the Module Features

+

Simple interceptor-style authorization

-
-

SecurityBinding for Class and Method Invocations

This feature of the Security module intercepts method calls and performs a security check before invocation is allowed to proceed.

-

In order to use the DeltaSpike security module, you must first have -installed the proper dependencies into the pom.xml file. Once this is -complete, you may proceed to create a security parameter binding -annotation. This is what we will use to add security behavior to our -business classes and methods.

+

The first piece of code required to use this API is a security binding annotation. This is what we will use to add security behavior to our business classes and methods.

-
Create the SecurityBinding
+
Create the security binding annotation
@Retention(value = RUNTIME)
 @Target({TYPE, METHOD})
 @Documented
 @SecurityBindingType
-public @interface CustomSecurityBinding {
-}
+public @interface UserLoggedIn {}
-

Next, we must define an Authorizer class to implement behavior for our -custom SecurityBindingType. This class is simply a CDI bean which -declares a @Secures method, qualified with the security binding +

Next, we must define an authorizer class to implement behavior for our +custom security binding type. This class is simply a CDI bean which +declares a method annotated @Secures, qualified with the security binding annotation we created in the first step.

-

This method has access to the InvocationContext of the method call, so +

This method has access to the InvocationContext of the method call, so if we need to access parameter arguments, we can do so using the given context. Note that we may also inject other beans into the parameter -list of our @Secures method.

+list of our authorizer method.

-
Create the Authorizer
+
Create the authorizer
@ApplicationScoped
-public class CustomAuthorizer
+public class LoggedInAuthorizer
 {
     @Secures
-    @CustomSecurityBinding
+    @UserLoggedIn
     public boolean doSecuredCheck(InvocationContext invocationContext, BeanManager manager, Identity identity) throws Exception
     {
         return identity.isLoggedIn(); // perform security check
@@ -383,15 +391,15 @@ list of our @Secures method.

We can then use our new annotation to secure business or bean methods. This binding annotation may be placed on the entire class (securing all -methods,) or on individual methods that you wish to secure.

+methods) or on individual methods that you wish to secure.

-
Secure a Bean Method
+
Secure a bean method
@ApplicationScoped
 public class SecuredBean1
 {
-    @CustomSecurityBinding
+    @UserLoggedIn
     public void doSomething(Thing thing)
     {
         thing.doSomething();
@@ -401,11 +409,11 @@ methods,) or on individual methods that
 

Next, we may access parameter values from the method invocation directly -in our authorizer bean by creating custom @SecurityParameterBinding +in our authorizer bean by creating custom @SecurityParameterBinding types; this is a simple step once we have completed the work above:

-
Create a Parameter Binding Annotation
+
Create a parameter binding annotation
@Retention(value = RUNTIME)
 @Target({PARAMETER})
@@ -421,13 +429,13 @@ values as arguments into our authorizer
 security in our applications:

-
Update the Authorizer to use Parameter Binding
+
Update the authorizer to use parameter binding
@ApplicationScoped
 public class CustomAuthorizer
 {
     @Secures
-    @CustomSecurityBinding
+    @UserLoggedIn
     public boolean doSecuredCheck(InvocationContext invocationContext, BeanManager manager, Identity identity, @CurrentThing Thing thing) throws Exception
     {
         return thing.hasMember(identity); // perform security check against our method parameter
@@ -444,7 +452,7 @@ security in our applications:

@ApplicationScoped
 public class SecuredBean1
 {
-    @CustomSecurityBinding
+    @UserLoggedIn
     public void doSomething(@CurrentThing Thing thing)
     {
         thing.doSomething();
@@ -467,7 +475,7 @@ case:

@ApplicationScoped
 public class SecuredBean1
 {
-    @CustomSecurityBinding
+    @UserLoggedIn
     public Thing loadSomething()
     {
         return thingLoader.load();
@@ -477,7 +485,7 @@ case:

Now you need to access the return value in the authorizer method. You -can inject it using the @SecuredReturn annotation. Update the Authorizer +can inject it using the @SecuredReturn annotation. Update the authorizer to use a secured return value:

@@ -486,7 +494,7 @@ to use a secured return value:

public class CustomAuthorizer { @Secures - @CustomSecurityBinding + @UserLoggedIn public boolean doSecuredCheck(@SecuredReturn Thing thing, Identity identity) throws Exception { return thing.hasMember(identity); // perform security check against the return value @@ -497,38 +505,13 @@ to use a secured return value:

Now the authorization will take place after the method invocation using the return value of the business method.

-
-
Complete the Parameter Binding
-
-
@ApplicationScoped
-public class SecuredBean1
-{
-    @CustomSecurityBinding
-    public void doSomething(@CurrentThing Thing thing)
-    {
-        thing.doSomething();
-    }
-}
-
-
-

Our method is now secured, and we are able to use given parameter values -as part of our security authorizer!

-
-
-

Integrating Third-party Security Frameworks

-
-

@Secured

+
+

Advanced authorization

+
-

@Secured is build on @SecurityBindingType and a very simple -alternative to the rest of the security module. It is a basic hook to -integrate a custom security concept, third-party frameworks, etc. It -does not provide a full blown security concept like the rest of the -security module, but other DeltaSpike modules ensure that the security -concepts are integrated properly (e.g. correct behaviour within custom -scope implementations,…​). It just allows to integrate other security -frameworks easily.

+

This is an alternative to the simple annotation-based interceptor-style API. This API uses the annotation @Secured and is mainly a hook for integration of custom security concepts and third-party frameworks. The DeltaSpike Security module is not a full application security solution, but some of the other DeltaSpike modules are security-enabled and use this API (e.g. correct behaviour within custom scope implementations,…​). Internally, this @Secured API uses the @Secures/@SecurityBindingType API.

(In MyFaces CODI it was originally a CDI interceptor. This part changed @@ -537,6 +520,9 @@ a bit, because between the interceptor a approach. Therefore the basic behaviour remains the same and you can think about it like an interceptor.)

+
+

The entry point to this API is the @Secured annotation placed either on the whole class — enabling security for all methods — or on individual methods. The only other prerequisite is at least one AccessDecisionVoter implementation, explained in the next section.

+
Securing All Intercepted Methods of a CDI Bean
@@ -562,11 +548,10 @@ think about it like an interceptor.)

}
-
-
-

AccessDecisionVoter

+
+

AccessDecisionVoter

-

This interface is (besides the Secured annotation) the most important +

This interface is (besides the @Secured annotation) the most important part of the concept. Both artifact types are also the only required parts:

@@ -584,18 +569,14 @@ parts:

}
-
-

[TODO] tip about the changed parameter/s

-
-
-

SecurityViolation

+
+

SecurityViolation

In case of a detected violation a SecurityViolation has to be added to the result returned by the AccessDecisionVoter.

-

AbstractAccessDecisionVoter

@@ -617,8 +598,9 @@ This is a convenience class which allows }
-
-

@Secured and Stereotypes with Custom Meta-data

+
+
+

@Secured and stereotypes with custom metadata

If there are multiple AccessDecisionVoter and maybe in different constellations, it is easier to provide an expressive CDI stereotypes for @@ -644,10 +626,10 @@ place.

-

Furthermore, it is possible to provide custom meta-data easily.

+

Furthermore, it is possible to provide custom metadata easily.

-
Stereotype of @Secured with Custom Meta-data
+
Stereotype of @Secured with custom metadata
@Named
 @Admin(securityLevel=3)
@@ -679,156 +661,6 @@ place.

- -
-

Making Intitially Requested and Secured Page available for Redirect after Login

-
-

DeltaSpike can be combined with pure CDI or with any other security -frameworks (like PicketLink) to track the denied page and make it -available after user logs in.

-
-
-

CDI Implementation to Redirect the Login to the First Denied Page

-
-

Your LoginService will fire a custom UserLoggedInEvent

-
-
-
-
public class LoginService implements Serializable {
-
-    @Inject
-    private Event<UserLoggedInEvent> userLoggedInEvent;
-
-    public Usuario login(String username, char[] password) {
-        //do the loggin process
-        userLoggedInEvent.fire(new UserLoggedInEvent());
-    }
-
-}
-
-
-
-

Use @SessionScoped or @WindowScoped for AdminAccessDecisionVoter and -store the denied page on your own.

-
-
-
-
@SessionScoped //or @WindowScoped
-public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
-
-    @Inject
-    private ViewConfigResolver viewConfigResolver;
-
-    private Class<? extends ViewConfig> deniedPage = Pages.Home.class;
-
-    @Override
-    protected void checkPermission(AccessDecisionVoterContext context, Set<SecurityViolation> violations) {
-        if(loggedIn) {
-            //...
-        } else {
-            violations.add(/*...*/);
-            deniedPage = viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
-        }
-    }
-
-    public Class<? extends ViewConfig> getDeniedPage() {
-        try {
-            return deniedPage;
-        } finally {
-            deniedPage = Pages.Home.class;
-        }
-    }
-}
-
-
-
-

And in AuthenticationListener you inject AdminAccessDecisionVoter

-
-
-
-
public class AuthenticationListener {
-
-    @Inject
-    private ViewNavigationHandler viewNavigationHandler;
-
-    @Inject
-    private AdminAccessDecisionVoter adminAccessDecisionVoter;
-
-    public void handleLoggedIn(@Observes UserLoggedInEvent event) {
-        this.viewNavigationHandler.navigateTo(adminAccessDecisionVoter.getDeniedPage());
-    }
-
-}
-
-
-
-
- -
-

Once that PicketLink handles the authentication for you, you only need -to store the denied page and observe PicketLink LoggedInEvent to -redirect you back to the denied page.

-
-
-

Use @SessionScoped or @WindowScoped for AdminAccessDecisionVoter and -store the denied page on your own.

-
-
-
-
@SessionScoped //or @WindowScoped
-public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
-
-    @Inject
-    private ViewConfigResolver viewConfigResolver;
-
-    private Class<? extends ViewConfig> deniedPage = Pages.Home.class;
-
-    @Override
-    protected void checkPermission(AccessDecisionVoterContext context, Set<SecurityViolation> violations) {
-
-        AuthorizationChecker authorizationChecker = BeanProvider.getContextualReference(AuthorizationChecker.class);
-        boolean loggedIn = authorizationChecker.isLoggedIn();
-
-        if(loggedIn) {
-            //...
-        } else {
-            violations.add(/*...*/);
-            deniedPage = viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
-        }
-    }
-
-    public Class<? extends ViewConfig> getDeniedPage() {
-        try {
-            return deniedPage;
-        } finally {
-            deniedPage = Pages.Home.class;
-        }
-    }
-}
-
-
-
-

And in AuthenticationListener you inject AdminAccessDecisionVoter

-
-
-
-
public class AuthenticationListener {
-
-    @Inject
-    private ViewNavigationHandler viewNavigationHandler;
-
-    @Inject
-    private AdminAccessDecisionVoter adminAccessDecisionVoter;
-
-    public void handleLoggedIn(@Observes LoggedInEvent event) {
-        this.viewNavigationHandler.navigateTo(adminAccessDecisionVoter.getDeniedPage());
-    }
-
-}
-
-
-
-

AccessDecisionVoterContext

@@ -858,8 +690,9 @@ the results of the security check.

-
-

SecurityStrategy SPI

+
+
+

SecurityStrategy SPI

The SecurityStrategy interface allows to provide a custom implementation which should be used for @Secured. Provide a custom @@ -883,13 +716,39 @@ implementation as bean-class in combinat -The configuration for global-alternatives is following the pattern: -globalAlternatives.<interface-name>=<implementation-class-name> +The configuration for global alternatives is following the pattern: +globalAlternatives.<interface-name>=<implementation-class-name>

+
+

Examples

+
+

Redirect to requested page after login

+
+

DeltaSpike can be combined with pure CDI or with any other security +frameworks (like PicketLink) to track the denied page and make it +available after user logs in.

+
+
+

An example of this use case is available in the examples module in the DeltaSpike repository:

+
+ +
+

The relevant classes are AuthenticationListener and LoggedInAccessDecisionVoter.

+
+
@@ -918,36 +777,24 @@ globalAlternatives.<interface-n
-

Configure Your Projects

+

Project Setup

The configuration information provided here is for Maven-based projects and it assumes that you have already declared the DeltaSpike version and DeltaSpike Core module for your projects, as detailed in Configure DeltaSpike in Your Projects. For Maven-independent projects, see Configure DeltaSpike in Maven-independent Projects.

@@ -309,11 +309,8 @@ table.CodeRay td.code>pre{padding:0}
- - -
-

2. Configure Listeners and Filters

-
+
+

2. Configure Listeners and Filters

In most cases there is no need for any additional configuration beside adding the required dependencies to your project, because all required @@ -384,11 +381,10 @@ register the listeners and filters in yo

+
-

Use the Module Features

+

Injectable Servlet Objects

-
-

Injectable Servlet Objects

The DeltaSpike Servlet module contains producers for many objects of a Servlet environment. All produces are using the special qualifier @@ -404,8 +400,8 @@ injection of some Servlet objects out of private ServletObject servletObject;

-
-

ServletContext

+
+

ServletContext

The ServletContext is made available in the application scope. It can be injected into any CDI bean like this:

@@ -417,8 +413,8 @@ be injected into any CDI bean like this:
-
-

ServletRequest / HttpServletRequest

+
+

ServletRequest / HttpServletRequest

The ServletRequest is made available in the request scope. The current request can be injected into a CDI bean like this:

@@ -439,8 +435,8 @@ request can be injected into a CDI bean
-
-

ServletResponse / HttpServletResponse

+
+

ServletResponse / HttpServletResponse

The ServletResponse is made available in the request scope. The current response can be injected into a CDI bean like this:

@@ -461,8 +457,8 @@ current response can be injected into a
-
-

HttpSession

+
+

HttpSession

The HttpSession is made available in the session scope. You can inject the current session of a user into a CDI bean like this:

@@ -478,8 +474,8 @@ the current session of a user into a CDI of a session.

-
-

Principal

+
+

Principal

The Principal is made available in the request scope. The current principal can be injected into a CDI bean like this:

@@ -496,8 +492,10 @@ principal can be injected into a CDI bea
-
-

Servlet Event Propagation

+
+
+

Servlet Event Propagation

+

The DeltaSpike Servlet module propagates a number of Servlet object lifecycle events to the CDI event bus. This allows regular CDI beans to @@ -512,8 +510,8 @@ object, DeltaSpike uses the qualifiers <

The following sections shows which concrete Servlet objects are supported and how their lifecycle can be observed.

-
-

Servlet Context Lifecycle Events

+
+

Servlet Context Lifecycle Events

The Servlet module supports initialization and destruction events for the ServletContext. These events can for example be used to detect @@ -547,8 +545,8 @@ also simply remove the entry for the web.xml to disable the events.

-
-

Request and Response Lifecycle Events

+
+

Request and Response Lifecycle Events

The Servlet module also supports initialization and destruction events for the HttpServletRequest and HttpServletResponse. These events can @@ -601,8 +599,8 @@ also simply remove the entry for the web.xml to disable the events.

-
-

Session Lifecycle Events

+
+

Session Lifecycle Events

The last category of events supported by the DeltaSpike Servlet module are the lifecycle events for the user’s HTTP session. The following @@ -637,7 +635,6 @@ your web.xml to disable the

-
@@ -663,16 +660,14 @@ your web.xml to disable the
Modified: websites/staging/deltaspike/trunk/content/documentation/test-control.html ============================================================================== --- websites/staging/deltaspike/trunk/content/documentation/test-control.html (original) +++ websites/staging/deltaspike/trunk/content/documentation/test-control.html Tue May 12 18:37:24 2015 @@ -281,7 +281,7 @@ table.CodeRay td.code>pre{padding:0}
-

Configure Your Projects

+

Project Setup

The configuration information provided here is for Maven-based projects and it assumes that you have already declared the DeltaSpike version and DeltaSpike Core module for your projects, as detailed in Configure DeltaSpike in Your Projects. For Maven-independent projects, see Configure DeltaSpike in Maven-independent Projects.

@@ -395,12 +395,10 @@ of dependencies instead of the OpenWebBe
-

Use the Module Features

+

Automated Container Booting and Shutdown

-

Automated Container Booting and Shutdown

-
-

CdiTestRunner

+

CdiTestRunner

Start and stop the CDI container automatically per test class with CdiTestRunner, a JUnit Test-Runner. This also starts and stops one request and session per test-method.

@@ -425,8 +423,8 @@ This also starts and stops one request a
-
-

CdiTestSuiteRunner

+
+

CdiTestSuiteRunner

Extend automated CDI container start and stop actions to whole test suites with CdiTestSuiteRunner, a JUnit Test-Suite-Runner.

@@ -444,17 +442,19 @@ This also starts and stops one request a
-
-

Optional Shutdown Configuration

+
+

Optional Shutdown Configuration

You can set deltaspike.testcontrol.stop_container to false (via the standard DeltaSpike config), resulting in the CDI Container being started just once for all tests.

+
+
+

Test Customization

+
-

Test Customization

-
-

@TestControl

+

@TestControl

Customize the default behavior of CdiTestRunner with @TestControl. In the following case only one session for all test-methods (of the test-class) will be @@ -472,8 +472,8 @@ created.

-
-

ProjectStage Control

+
+

ProjectStage Control

Override the default ProjectStage for unit tests with ProjectStage.UnitTest.class.

@@ -498,8 +498,10 @@ created.

-
-

Optional Configuration

+
+
+

Optional Configuration

+

From DeltaSpike 1.2, it is possible to provide a configuration for the underlying test-container. However, currently only the adapter for OpenEJB embedded (available in CDI-Control) supports it out-of-the-box. @@ -510,8 +512,8 @@ The content of the file are key/value pa Therefore, it is a configuration which is not used by DeltaSpike itself (it is just forwarded (as it is) to the underlying test-container).

-
-

Reconfigure the config-file Name or Location

+
+

Reconfigure the config-file Name or Location

If you would like to point to an existing config-file, you have to add for example:

@@ -533,10 +535,12 @@ Therefore, it is a configuration which i
+
+
+

Optional Integrations

+
-

Optional Integrations

-
-

Mock Frameworks

+

Mock Frameworks

From DeltaSpike 1.0, it is possible to mock CDI-Beans. Usually @Exclude (+ ProjectStage) is enough, however, for some cases mocked beans might be @@ -738,8 +742,8 @@ mocked implementation via @Exclude constructor) and specify the target-type via @TypedMock.

-
-

JSF (via MyFaces-Test)

+
+

JSF (via MyFaces-Test)

add on of

@@ -770,8 +774,10 @@ constructor) and specify the target-type
-
-

Using jersey-test with test-control

+
+
+

Using jersey-test with test-control

+

Jersey-test starts jetty which answers requests in a separated thread. Since ds test-control just handles the thread of the test itself, it’s needed to integrate jetty and jersey with the cdi-container. Usually that’s done via a ServletRequestListener - the following part describes an alternative approach for jersey-test:

@@ -855,8 +861,10 @@ cdiHandlerWrapper.setHandler(
-
-

Mixed Tests

+
+
+

Mixed Tests

+

Usually you should have one kind of tests per test-module. However, if you need to add, for example, a test without an external-container to your @@ -874,10 +882,12 @@ with:

+
+
+

Known Restrictions

+
-

Known Restrictions

-
-

Liquibase

+

Liquibase

Liquibase invokes #toString in a AfterDeploymentValidation observer. that is not portable and therefore you have to deactivate the @@ -905,8 +915,8 @@ mocking-support via:

Further details are available at deactivatable.

-
-

Gradle

+
+

Gradle

Gradle by default does not put resources and compiled sources in to the same directory. When running a test using Gradle, this means your classes will not be in bean archives as @@ -929,10 +939,12 @@ for resources to point to where the comp

+
+
+

SPI

+
-

SPI

-
-

ExternalContainer

+

ExternalContainer

org.apache.deltaspike.testcontrol.spi.ExternalContainer allows to integrate containers which get started after the CDI container. @@ -948,7 +960,6 @@ Currently DeltaSpike provides:

-
@@ -983,7 +994,7 @@ Currently DeltaSpike provides: