Apache Redback - Introduction

; Wed, 19 Sep 2012 10:18:32 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1387511 [2/6] - in /archiva/site-content/redback: ./ css/ development/ images/ images/logos/ images/profiles/ img/ integration/ js/ rbac/ Date: Wed, 19 Sep 2012 10:18:31 -0000 To: commits@archiva.apache.org From: olamy@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20120919101832.EBC7123889E2@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Added: archiva/site-content/redback/index.html URL: http://svn.apache.org/viewvc/archiva/site-content/redback/index.html?rev=1387511&view=auto ============================================================================== --- archiva/site-content/redback/index.html (added) +++ archiva/site-content/redback/index.html Wed Sep 19 10:18:29 2012 @@ -0,0 +1,248 @@ + + + + + + + + + + Apache Redback - Introduction + + + + + + + + + + + + + + + + + + + + + + + +

+ + +

+ +

+ + + +

+ +

Introduction

Redback started as an attempt to clean away some of the more annoying security related components of web applications and centralize them into a simple to use framework. Some of the basic beliefs we started with where that authentication, authorization and user management were all basically seperate concerns, sure there are points where they rub up against each other but those are pretty clear points and not worth mashing up whole discrete concepts together.

Redback supports a number of authentication mechanisms, and a couple of authorization schemes including an implementation of role based access control. Redback has been built on top of the plexus container so it is simple to have the core security system object into your code for making authentication, authorization or user management tasks through its api. We also provide a war overlay based on xwork which provides all of the user management, authentication and remember me and single sign on functionalities. An easy to use taglib allows you to include authorization conditional functionalities to your jsps.

Redback is currently being used for providing a consistent security related user experience to Apache Continuum and Archiva.

+ +

+ + + + \ No newline at end of file Added: archiva/site-content/redback/integration.html URL: http://svn.apache.org/viewvc/archiva/site-content/redback/integration.html?rev=1387511&view=auto ============================================================================== --- archiva/site-content/redback/integration.html (added) +++ archiva/site-content/redback/integration.html Wed Sep 19 10:18:29 2012 @@ -0,0 +1,248 @@ + + + + + + + + + + Apache Redback - Plexus Security Integration Points + + + + + + + + + + + + + + + + + + + + + + + +

+ + +

+ +

+ + + +

+ +

Plexus Security Integration

+ +

+ + + + \ No newline at end of file Added: archiva/site-content/redback/integration/general.html URL: http://svn.apache.org/viewvc/archiva/site-content/redback/integration/general.html?rev=1387511&view=auto ============================================================================== --- archiva/site-content/redback/integration/general.html (added) +++ archiva/site-content/redback/integration/general.html Wed Sep 19 10:18:29 2012 @@ -0,0 +1,248 @@ + + + + + + + + + + Apache Redback - Integration Points + + + + + + + + + + + + + + + + + + + + + + + +

+ + +

+ +

+ + + +

+ +

Redback Integration

Currently there is only one integration available for use with redback. We provide a webapp overlay that will seamlessly integrate with a webwork application to provide virtually all of your security needs. It comes configured with default system administrator roles and a host of other features. For a complete listing of what comes with the webwork integration just look for that guide.

+ +

+ + + + \ No newline at end of file Added: archiva/site-content/redback/integration/ldap.html URL: http://svn.apache.org/viewvc/archiva/site-content/redback/integration/ldap.html?rev=1387511&view=auto ============================================================================== --- archiva/site-content/redback/integration/ldap.html (added) +++ archiva/site-content/redback/integration/ldap.html Wed Sep 19 10:18:29 2012 @@ -0,0 +1,338 @@ + + + + + + + + + + Apache Redback - Ldap Integration + + + + + + + + + + + + + + + + + + + + + + + +

+ + +

+ +

+ + + +

+ +

Redback Ldap Integration

NOTE: This has changed dramatically and may not be correct.

With the alpha-3 release of redback limited support for ldap has been added as an authentication source. Limited support for ldap means:

Read-Only User Management
xml and properties based configuration
tested against open ldap on linux and apacheds 1.5.0

Setting up Ldap

Configuration for ldap is actually a relatively simple procedure, a few components definitions need to be declared in an appropriate application.xml and then some configuration options must be set in the security.properties file.

The application.xml Additions

These components should be defined in the applicable application.xml

ldap connection factory

+  <component>
+      <role>org.apache.archiva.redback.common.ldap.connection.LdapConnectionFactory</role>
+      <role-hint>configurable</role-hint>
+      <implementation>org.apache.archiva.redback.common.ldap.connection.ConfigurableLdapConnectionFactory</implementation>
+      <description></description>
+      <configuration>
+        <hostname></hostname>
+        <port></port>
+        <baseDn></baseDn>
+        <contextFactory>com.sun.jndi.ldap.LdapCtxFactory</contextFactory>
+        <password></password>
+        <bindDn></bindDn>
+      </configuration>
+    </component>
+

hostname - The hostname of the ldap server
port - The port of the ldap server
baseDn - The baseDn of the ldap system
contextFactory - context factory for ldap connections
password - password for the bindDn for the root ldap connection
bindDn - the core user used for authentication the ldap server, must be able to perform the necessary searches, etc.

user mapper

        
+    <component>
+      <role>org.apache.archiva.redback.common.ldap.UserMapper</role>
+      <role-hint>ldap</role-hint>
+      <implementation>org.apache.archiva.redback.common.ldap.LdapUserMapper </implementation>
+      <description></description>
+      <configuration>
+        <email-attribute>email</email-attribute>
+        <full-name-attribute>givenName</full-name-attribute>
+        <password-attribute>userPassword</password-attribute>
+        <user-id-attribute>cn</user-id-attribute>
+        <user-base-dn></user-base-dn>
+        <user-object-class>inetOrgPerson</user-object-class>
+        <user-filter>(|(attributeName=value1)(attributeName=value2))</user-filter>
+      </configuration>
+    </component>
+

email-attribute - The name of the attribute on a user that contains the email address
full-name-attribute - The name of the attribute on a user that contains the users fullName
password-attribute - The name of the attribute containing the users password, used for the authentiction using the user manager and not the ldap bind authenticator
user-id-attribute - The name of the attribute containing the users userId, most commonly cn or sn.
user-base-dn - The base dn that will be subtree searched for users.
user-object-class - the objectClass used in the ldap server for indentifying users, most commonly inetOrgPerson.
user-filter - the user filter is used to reduce the number of results during a LDAP request. It is optional.

security policy (for the password encoder)

  
+    <component>
+      <role>org.apache.archiva.redback.policy.UserSecurityPolicy</role>
+      <role-hint>default</role-hint>
+      <implementation>org.apache.archiva.redback.policy.DefaultUserSecurityPolicy</implementation>
+      <description>User Security Policy.</description>
+      <requirements>
+        <requirement>          <role>org.apache.archiva.redback.configuration.UserConfiguration</role>
+          <field-name>config</field-name>
+        </requirement>
+        <requirement>
+          <role>org.apache.archiva.redback.policy.PasswordEncoder</role>
+          <role-hint>sha1</role-hint>
+          <field-name>passwordEncoder</field-name>
+        </requirement>
+        <requirement>
+          <role>org.apache.archiva.redback.policy.UserValidationSettings</role>
+          <field-name>userValidationSettings</field-name>
+        </requirement>
+        <requirement>
+          <role>org.apache.archiva.redback.policy.CookieSettings</role>
+          <role-hint>rememberMe</role-hint>
+          <field-name>rememberMeCookieSettings</field-name>
+        </requirement>
+        <requirement>
+          <role>org.apache.archiva.redback.policy.CookieSettings</role>
+          <role-hint>signon</role-hint>
+          <field-name>signonCookieSettings</field-name>
+        </requirement>
+        <requirement>
+          <role>org.apache.archiva.redback.policy.PasswordRule</role>
+          <field-name>rules</field-name>
+        </requirement>
+      </requirements>
+    </component>
+

security.properties

These properties should be set as shown:

+user.manager.impl=ldap
+ldap.bind.authenticator.enabled=true
+redback.default.admin=admin
+redback.default.guest=guest
+security.policy.password.expiration.enabled=false
+

The user.manager.impl is the role hint that is used to determine which user manaher to use while running. The default is 'cached' and if this is desired to be used with ldap then you must include the component declartion below in the caching section for the cached UserManager that sets the underlying userImpl to ldap.

The ldap.bind.authenitcator.enabled boolean value will toggle the use of authenticator that will authenticate using the bind operation. There are two different mechanisms used to authenticate with ldap, either the bind authenticator which is a standard way to authentication, and then the user manager password validation approach. If this is desired then you must ensure that the security policy is configured to use the correct password encoding. Normally the bind authenticator is simply enabled since this bypasses concerns of password encoding.

It is also now possible to redefine the basic admin user and guest user names. Since its un likely that ldap oriented authentication systems will have a specific admin or guest user these can be redefined simply in the security.properties. Care must be taken that they exist in the ldap system since they are looked up. Guest users can be simple utilitie or application users.

The final setting of security.policy.password.expiration.enabled is a boolean that should be set to false for ldap based authentication. This is because redback will want to attempt to manage and enforce password expiration and that is no longer under the direction of redback but is an artifact of the ldap system in place. Setting this to false prevents issues from cropping up related to redback trying to obtain this type of information.

Caching

If caching is desired the you should also include the following declarition and set the appropriate configuration from ldap to cached

   
  <component>
+      <role>org.apache.archiva.redback.users.UserManager</role>
+      <role-hint>cached</role-hint>
+      <implementation> org.apache.archiva.redback.users.cached.CachedUserManager</implementation>
+      <description>CachedUserManager</description>
+      <requirements>
+        <requirement>
+          <role> org.apache.archiva.redback.users.UserManager</role>
+          <role-hint>ldap</role-hint>
+          <field-name>userImpl</field-name>
+        </requirement>
+        <requirement>
+          <role>org.apache.archiva.redback.components.cache.Cache</role>
+          <role-hint>users</role-hint>
+          <field-name>usersCache</field-name>
+        </requirement>
+      </requirements>
+    </component>
+

+ +

+ + + + \ No newline at end of file Added: archiva/site-content/redback/integration/plugins.html URL: http://svn.apache.org/viewvc/archiva/site-content/redback/integration/plugins.html?rev=1387511&view=auto ============================================================================== --- archiva/site-content/redback/integration/plugins.html (added) +++ archiva/site-content/redback/integration/plugins.html Wed Sep 19 10:18:29 2012 @@ -0,0 +1,335 @@ + + + + + + + + + + Apache Redback - Webwork Integration + + + + + + + + + + + + + + + + + + + + + + + +

+ + +

+ +

+ + + +

+ +

Plugin Configuration

NOTE: This has changed dramatically and may not be correct.

Then you will also want to setup the following plugins in the build section of the webapp's pom as well. Briefly, the maven-clean-plugin needs to be configured a little bit to point to the different locations of files to be cleaned. The maven-war-plugin is being used to pull in the plexus-security war overlay and unpackage it into place so the relavent jsp's and actions are available. Lastly is the jetty-maven-plugin which has some configuration to get datasources setup (the jetty-env.xml) and the port it will run on, etc.

       <plugin>
+        <groupId>org.apache.maven.plugins</groupId>
+        <artifactId>maven-clean-plugin</artifactId>
+        <version>2.1.1</version>
+        <!-- This configuration is added to cleanup from war:inplace -->
+        <configuration>
+          <filesets>
+            <fileset>
+              <directory>${basedir}/</directory>
+              <includes>
+                <include>derby.log</include>
+              </includes>
+            </fileset>
+            <fileset>
+              <directory>${basedir}/src/main/webapp</directory>
+              <includes>
+                <!-- TODO: META-INF shouldn't be required, seems to be an issue with the current war plugin -->
+                <include>META-INF</include>
+                <include>WEB-INF/classes</include>      <!-- Classes and Resources from other wars -->
+                <include>WEB-INF/lib</include>          <!-- Dependencies from other wars -->
+                <include>WEB-INF/database</include>     <!-- Database location configured in application.xml -->
+                <include>WEB-INF/logs</include>         <!-- Log file location specified in application.xml -->
+                <include>pss</include>                  <!-- plexus-security css and javascript -->
+                <include>WEB-INF/jsp/pss</include>      <!-- plexus-security jsps -->
+                <include>WEB-INF/template/pss</include> <!-- plexus-security xwork templates -->
+              </includes>
+            </fileset>
+          </filesets>
+        </configuration>
+      </plugin>
+      <plugin>
+        <groupId>org.apache.maven.plugins</groupId>
+        <artifactId>maven-war-plugin</artifactId>
+        <version>2.0.1</version>
+        <configuration>
+          <!-- Some versions of maven-war-plugin (snapshots) have this incorrectly defaulted to true.
+               Specifically setting this to false to avoid accidental jar file creation. -->
+          <archiveClasses>false</archiveClasses>
+          <dependentWarExcludes>META-INF/**,WEB-INF/web.xml,WEB-INF/classes/xwork.xml</dependentWarExcludes>
+        </configuration>
+        <!-- TODO: would be good to make the jetty plugin aware of these and remove the below -->
+                <executions>
+          <execution>
+            <phase>compile</phase>
+            <goals>
+              <!-- Needed to get the plexus-security war overlay to do its thing before jetty:run -->
+              <goal>inplace</goal>
+            </goals>
+          </execution>
+        </executions>
+      </plugin>
+      <plugin>
+        <groupId>org.mortbay.jetty</groupId>
+        <artifactId>maven-jetty-plugin</artifactId>
+        <version>6.0.1</version>
+        <configuration>
+          <scanIntervalSeconds>10</scanIntervalSeconds>
+          <contextPath>/</contextPath>
+          <jettyEnvXml>${basedir}/src/jetty-env.xml</jettyEnvXml>
+          <connectors>
+            <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
+              <port>9090</port>
+              <maxIdleTime>60000</maxIdleTime>
+            </connector>
+          </connectors>
+        </configuration>
+      </plugin>

If you are planning on writing your own webwork actions, then your'll need to generally make this available so that your actions are rendered into components correctly if you are not generating your components.xml by hand. This will setup your actions as per-look instantiations, so that every page served results in a new action being generated. This is currently the standard way to using xwork with plexus.

+      <plugin>
+        <groupId>org.codehaus.plexus</groupId>
+        <artifactId>plexus-maven-plugin</artifactId>
+        <configuration>
+          <roleDefaults>
+            <roleDefault>
+              <role>com.opensymphony.xwork.Action</role>
+              <instantiation-strategy>per-lookup</instantiation-strategy>
+            </roleDefault>
+          </roleDefaults>
+        </configuration>
+        <executions>
+          <execution>
+            <id>generate</id>
+            <goals>
+              <goal>descriptor</goal>
+            </goals>
+          </execution>
+        </executions>
+      </plugin>
+

+ +

+ + + + \ No newline at end of file