From seam-commits at lists.jboss.org Mon Jun 23 20:55:52 2008 Content-Type: multipart/mixed; boundary="===============2106935707200269124==" MIME-Version: 1.0 From: seam-commits at lists.jboss.org To: seam-commits at lists.jboss.org Subject: [seam-commits] Seam SVN: r8405 - trunk/doc/Seam_Reference_Guide/en-US. Date: Mon, 23 Jun 2008 20:55:51 -0400 Message-ID: --===============2106935707200269124== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: shane.bryzak(a)jboss.com Date: 2008-06-23 20:55:51 -0400 (Mon, 23 Jun 2008) New Revision: 8405 Modified: trunk/doc/Seam_Reference_Guide/en-US/Security.xml Log: more detail added to authorization section Modified: trunk/doc/Seam_Reference_Guide/en-US/Security.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/doc/Seam_Reference_Guide/en-US/Security.xml 2008-06-23 19:33:06 U= TC (rev 8404) +++ trunk/doc/Seam_Reference_Guide/en-US/Security.xml 2008-06-24 00:55:51 U= TC (rev 8405) @@ -1040,7 +1040,7 @@ Property - Default + Default Value Description @@ -1408,16 +1408,59 @@ = + = + + LdapIdentityStore Configuration Example + = + + The following configuration example shows how LdapIdent= ityStore may be configured for + an LDAP directory running on fictional host directory.m= ycompany.com. The users are stored + within this directory under the context ou=3DPerson,dc= =3Dmycompany,dc=3Dcom, and are identified + using the uid attribute (which corresponds to= their username). Roles are stored in their + own context, ou=3DRoles,dc=3Dmycompany,dc=3Dcom and referenced from the user's entry via the = + roles attribute. Role entries are identified= by their common name (the cn attribute) + , which corresponds to the role name. In this example, users ma= y be disabled by setting the value of their = + enabled attribute to false. + + = + ]]> + = + + = - Writing your own IdentityStore implementation + Writing your own IdentityStore = + Writing your own identity store implementation allows you to authe= nticate and perform identity management + operations against sources that aren't supported out of the box by= Seam. Only a single class is = + required to achieve this, and it must implement the + org.jboss.seam.security.management.IdentityStore interface. + = + + Please refer to the JavaDoc for IdentityStore f= or a description of the methods that + must be implemented. = + = Authentication with Identity Management = @@ -1524,7 +1567,7 @@ There are a number of authorization features provided by the Seam Se= curity API for securing access to components, component methods, and pages. This section describes ea= ch of these. An important thing to note is that if you wish to use any of the advanced features (such a= s rule-based permissions) then - your components.xml must be configured to support= this - see the Configuration section + your components.xml may need to be configured to = support this - see the Configuration section above. = @@ -1532,20 +1575,61 @@ Core concepts = - Each of the authorization mechanisms provided by the Seam Security= API are built upon the concept of a user - being granted roles and/or permissions. A role is a gro= up, or type, - of user that may have been granted certain privileges for performi= ng one or more specific actions within an - application. A permission on the other hand is a privilege (someti= mes once-off) for performing a single, - specific action. It is entirely possible to build an application = using nothing but permissions, however - roles offer a higher level of convenience when granting privileges= to groups of users. + Seam Security is built around the premise of users being granted r= oles and/or permissions, allowing them to + perform operations that may not otherwise be permissible for users= without the necessary security privileges. + Each of the authorization mechanisms provided by the Seam Security= API are built upon this core concept of roles and + permissions, with an extensible framework providing multiple ways = to secure application resources. = - - Roles are simple, consisting of only a name such as "admin", "user= ", "customer", etc. Permissions consist of - both a name and an action, and are represented within this documen= tation in the form name:action, - for example customer:delete, or custom= er:insert. - + + What is a role? + = + + A role is a group, or type, of user that may have been granted certain = + privileges for performing one or more specific actions within an= application. They are simple constructs, consisting = + of just a name such as "admin", "user", "customer", etc. They c= an be granted either to users (or in some cases to other = + roles), and are used to create logical groups of users for the c= onvenient assignment of specific application privileges. + = + + + + + + + + = + + = + + What is a permission? + = + + A permission is a privilege (sometimes once-off) for performing = a single, specific action. It is entirely possible to = + build an application using nothing but permissions, however role= s offer a higher level of convenience when granting = + privileges to groups of users. They are slightly more complex i= n structure than roles, essentially consisting of three = + "aspects"; a target, an action, and a recipient. The target of = a permission is the object (or an arbitrary name or class) = + for which a particular action is allowed to be performed by a sp= ecific recipient (or user). For example, the user "Bob" = + may have permission to delete customer objects. In this case, t= he permission target may be "customer", the permission = + action would be "delete" and the recipient would be "Bob". + + = + + + + + + + + + = + = + + Within this documentation, permissions are represented in the fo= rm name:action (generally + omitting the recipient, although in reality one is always requir= ed). + = + + = @@ -1555,6 +1639,16 @@ Let's start by examining the simplest form of authorization, compo= nent security, starting with the @Restrict annotation. + = + + @Restrict vs Typesafe security annotations + = + + While using the @Restrict annotation provides= a powerful and flexible method for security component methods + due to its ability to support EL expressions, it is recommended = that the typesafe equivalent (described later) be + used, at least for the compile-time safety it provides. + = + = The @Restrict annotation --===============2106935707200269124==--