[jboss-cvs] JBossAS SVN: r105611 - projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Jun 3 01:19:55 EDT 2010
Author: misty at redhat.com
Date: 2010-06-03 01:19:54 -0400 (Thu, 03 Jun 2010)
New Revision: 105611
Modified:
projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Security.xml
Log:
JBPAPP-4387
Modified: projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Security.xml
===================================================================
--- projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Security.xml 2010-06-03 01:06:29 UTC (rev 105610)
+++ projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Security.xml 2010-06-03 05:19:54 UTC (rev 105611)
@@ -94,7 +94,7 @@
Seam's simplified authentication method uses a built-in JAAS login module (<literal>SeamLoginModule</literal>) to delegate authentication to one of your own Seam components. (This module requires no additional configuration files, and comes pre-configured within Seam.) With this, you can write an authentication method with the entity classes provided by your own application, or authenticate through another third-party provider. Configuring this simplified authentication requires the <literal>identity</literal> component to be configured in <filename>components.xml</filename>
</para>
-<programlisting role="XML"><![CDATA[<components xmlns="http://jboss.com/products/seam/components"
+<programlisting language="XML" role="XML"><![CDATA[<components xmlns="http://jboss.com/products/seam/components"
xmlns:core="http://jboss.com/products/seam/core"
xmlns:security="http://jboss.com/products/seam/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -119,7 +119,7 @@
The <literal>authenticate-method</literal> property specified for <literal>identity</literal> in <filename>components.xml</filename> specifies the method used by <literal>SeamLoginModule</literal> to authenticate users. This method takes no parameters, and is expected to return a Boolean indicating authentication success or failure. Username and password are obtained from <literal>Credentials.getUsername()</literal> and <literal>Credentials.getPassword()</literal> respectively. (A reference to the <literal>credentials</literal> component can be obtained via <literal>Identity.instance().getCredentials()</literal>.) Any role that the user is a member of should be assigned with <literal>Identity.addRole()</literal>. The following is a complete example of an authentication method inside a POJO component:
</para>
-<programlisting role="JAVA"> <![CDATA[@Name("authenticator")
+<programlisting language="Java" role="JAVA">@Name("authenticator")
public class Authenticator {
@In EntityManager entityManager;
@In Credentials credentials;
@@ -145,7 +145,7 @@
}
-}]]>
+}
</programlisting>
<para>
In the example, both <literal>User</literal> and <literal>UserRole</literal> are application-specific entity beans. The <literal>roles</literal> parameter is populated with roles that the user is a member of. This is added to the <literal>Set</literal> as literal string values — for example, "admin", "user", etc. If the user record is not found, and a <literal>NoResultException</literal> is thrown, the authentication method returns <literal>false</literal> to indicate authentication failure.
@@ -179,14 +179,14 @@
If, upon successful login, some user statistics require updates, you can write an event observer for the <literal>org.jboss.seam.security.loginSuccessful</literal> event, like this:
</para>
-<programlisting role="JAVA"><![CDATA[
+<programlisting language="Java" role="JAVA">
@In UserStats userStats;
@Observer("org.jboss.seam.security.loginSuccessful")
public void updateUserStats() {
userStats.setLastLoginDate(new Date());
userStats.incrementLoginCount();
-}]]>
+}
</programlisting>
<para>
This observer method can be placed anywhere, even in the Authenticator component itself. More information about other security-related events appears later in the chapter.
@@ -201,7 +201,7 @@
The <literal>credentials</literal> component provides both <literal>username</literal> and <literal>password</literal> properties, catering for the most common authentication scenario. These properties can be bound directly to the username and password fields on a login form. Once these properties are set, calling <literal>identity.login()</literal> authenticates the user with the credentials provided. An example of a simple login form is as follows:
</para>
-<programlisting role="XHTML"><![CDATA[<div>
+<programlisting language="XML" role="XML"><![CDATA[<div>
<h:outputLabel for="name" value="Username"/>
<h:inputText id="name" value="#{credentials.username}"/>
</div>
@@ -264,7 +264,7 @@
No special configuration is required to enable the <emphasis>Remember Me</emphasis> feature for the default (safe, username-only) mode. In your login form, simply bind the <emphasis>Remember Me</emphasis> checkbox to <literal>rememberMe.enabled</literal>, as seen in the following example:
</para>
-<programlisting role="XHTML"><![CDATA[<div>
+<programlisting language="XML" role="XML"><![CDATA[<div>
<h:outputLabel for="name" value="User name"/>
<h:inputText id="name" value="#{credentials.username}"/>
</div>
@@ -288,7 +288,7 @@
First, create a new Entity to hold the tokens. The following is one possible structure:
</para>
-<programlisting role="JAVA"><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
public class AuthenticationToken implements Serializable {
private Integer tokenId;
private String username;
@@ -320,7 +320,7 @@
public void setValue(String value) {
this.value = value;
}
-}]]>
+}
</programlisting>
<para>
Several special annotations, <literal>@TokenUsername</literal> and <literal>@TokenValue</literal>, are used to configure the username and token properties of the entity. These annotations are required for the entity that holds the authentication tokens.
@@ -329,7 +329,7 @@
The next step is to configure <literal>JpaTokenStore</literal> to store and retrieve authentication tokens with this entity bean. Do this by specifying the <literal>token-class</literal> attribute in <filename>components.xml</filename>:
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:jpa-token-store
token-class="org.jboss.seam.example.seamspace.AuthenticationToken"/>]]>
</programlisting>
@@ -337,7 +337,7 @@
The final step is to configure the <literal>RememberMe</literal> component in <filename>components.xml</filename>. Its <literal>mode</literal> should be set to <literal>autoLogin</literal>:
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:remember-me mode="autoLogin"/>]]>
</programlisting>
<para>
@@ -347,7 +347,7 @@
To ensure that users are automatically authenticated when returning to the site, the following section should be placed in <filename>components.xml</filename>:
</para>
-<programlisting role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
+<programlisting language="XML" role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
<action execute="#{redirect.captureCurrentView}"/>
<action execute="#{identity.tryLogin()}"/>
</event>
@@ -380,7 +380,7 @@
In the case of a <exceptionname>NotLoggedInException</exceptionname>, we recommend the user be redirected to a login or registration page so that they can log in. For an <exceptionname>AuthorizationException</exceptionname>, it may be useful to redirect the user to an error page. Here's an example of a <filename>pages.xml</filename> file that redirects both of these security exceptions:
</para>
-<programlisting role="XML"><![CDATA[<pages>
+<programlisting language="XML" role="XML"><![CDATA[<pages>
...
@@ -412,7 +412,7 @@
When an unauthenticated user tries to access a particular view or wildcarded view ID, you can have Seam redirect the user to a login screen as follows:
</para>
-<programlisting role="XML"><![CDATA[<pages login-view-id="/login.xhtml">
+<programlisting language="XML" role="XML"><![CDATA[<pages login-view-id="/login.xhtml">
<page view-id="/members/*" login-required="true"/>
...
@@ -427,7 +427,7 @@
After the user logs in, we want to automatically redirect them to the action that required login. If you add the following event listeners to <filename>components.xml</filename>, attempts to access a restricted view while not logged in are remembered. Upon a successful login, the user is redirected to the originally requested view, with any page parameters that existed in the original request.
</para>
-<programlisting role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
+<programlisting language="XML" role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
<action execute="#{redirect.captureCurrentView}"/>
</event>
@@ -448,13 +448,13 @@
Although we do not recommend it unless absolutely necessary, Seam provides the means to authenticate with either HTTP Basic or HTTP Digest (RFC 2617) methods. For either form, you must first enable the <literal>authentication-filter</literal> component in <filename>components.xml</filename>:
</para>
-<programlisting role="XML"><![CDATA[<web:authentication-filter url-pattern="*.seam" auth-type="basic"/> ]]>
+<programlisting language="XML" role="XML"><![CDATA[<web:authentication-filter url-pattern="*.seam" auth-type="basic"/> ]]>
</programlisting>
<para>
To enable basic authentication, set <literal>auth-type</literal> to <literal>basic</literal>. For digest authentication, set it to <literal>digest</literal>. If you want to use digest authentication, you must also set the <literal>key</literal> and <literal>realm</literal>:
</para>
-<programlisting role="XML"><![CDATA[<web:authentication-filter url-pattern="*.seam" auth-type="digest"
+<programlisting language="XML" role="XML"><![CDATA[<web:authentication-filter url-pattern="*.seam" auth-type="digest"
key="AA3JK34aSDlkj" realm="My App"/> ]]>
</programlisting>
<para>
@@ -466,7 +466,7 @@
If using digest authentication, your authenticator class should extend the abstract class <literal>org.jboss.seam.security.digest.DigestAuthenticator</literal>, and use the <literal>validatePassword()</literal> method to validate the user's plain text password against the digest request. Here is an example:
</para>
-<programlisting role="JAVA"><![CDATA[public boolean authenticate() {
+<programlisting language="Java" role="JAVA">public boolean authenticate() {
try {
User user = (User) entityManager.createQuery(
"from User where username = "username")
@@ -477,7 +477,7 @@
} catch (NoResultException ex) {
return false;
}
-}]]>
+}
</programlisting>
</section>
@@ -494,7 +494,7 @@
If you prefer not to use the simplified JAAS configuration provided by the Seam Security API, you can use the default system JAAS configuration by adding a <literal>jaas-config-name</literal> property to <literal>components.xml</literal>. For example, if you use JBoss AS and want to use the <literal>other</literal> policy (which uses the <literal>UsersRolesLoginModule</literal> login module provided by JBoss AS), then the entry in <filename>components.xml</filename> would look like this:
</para>
-<programlisting role="XML"><![CDATA[<security:identity jaas-config-name="other"/>]]>
+<programlisting language="XML" role="XML"><![CDATA[<security:identity jaas-config-name="other"/>]]>
</programlisting>
<para>
Keep in mind that doing this does not mean that your user will be authenticated in your Seam application container — it instructs Seam Security to authenticate itself with the configured JAAS security policy.
@@ -533,14 +533,14 @@
The <literal>identityManager</literal> component has two configurable properties: <literal>identityStore</literal> and <literal>roleIndentityStore</literal>. The value for these properties must be an EL expression that refers to a Seam component with the <literal>IdentityStore</literal> interface. If left unconfigured, the default (<literal>JpaIdentityStore</literal>) will be used. If only the <literal>identityStore</literal> property is configured, the same value will be used for <literal>roleIdentityStore</literal>. For example, the following entry in <filename>components.xml</filename> will configure <literal>identityManager</literal> to use an <literal>LdapIdentityStore</literal> for both user-related and role-related operations:
</para>
-<programlisting role="XML"><![CDATA[<security:identity-manager identity-store="#{ldapIdentityStore}"/>
+<programlisting language="XML" role="XML"><![CDATA[<security:identity-manager identity-store="#{ldapIdentityStore}"/>
]]>
</programlisting>
<para>
The following example configures <literal>identityManager</literal> to use an <literal>LdapIdentityStore</literal> for user-related operations, and <literal>JpaIdentityStore</literal> for role-related operations:
</para>
-<programlisting role="XML"><![CDATA[<security:identity-manager identity-store="#{ldapIdentityStore}"
+<programlisting language="XML" role="XML"><![CDATA[<security:identity-manager identity-store="#{ldapIdentityStore}"
role-identity-store="#{jpaIdentityStore}"/>
]]>
</programlisting>
@@ -560,7 +560,7 @@
Both <literal>user-class</literal> and <literal>role-class</literal> must be configured before <literal>JpaIdentityStore</literal> can be used. These properties refer to the entity classes used to store user and role records, respectively. The following example shows the <filename>components.xml</filename> file from the SeamSpace example:
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:jpa-identity-store
user-class="org.jboss.seam.example.seamspace.MemberAccount"
role-class="org.jboss.seam.example.seamspace.MemberRole"/>
@@ -632,10 +632,10 @@
This annotation marks the field or method containing the user's password. It allows a <literal>hash</literal> algorithm to be specified for password hashing. Possible values for <literal>hash</literal> are <literal>md5</literal>, <literal>sha</literal> and <literal>none</literal>. For example:
</para>
-<programlisting role="JAVA"><![CDATA[@UserPassword(hash = "md5")
+<programlisting language="Java" role="JAVA">@UserPassword(hash = "md5")
public String getPasswordHash() {
return passwordHash;
-}]]>
+}
</programlisting>
<para>
It is possible to extend the <literal>PasswordHash</literal> component to implement other hashing algorithms, if required.
@@ -814,12 +814,12 @@
</imageobject>
</mediaobject>
-<programlisting role="JAVA"><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
public class User {
private Integer userId;
private String username;
private String passwordHash;
- private Set<Role> roles;
+ private Set<Role> roles;
@Id @GeneratedValue
public Integer getUserId() { return userId; }
@@ -840,12 +840,12 @@
@JoinTable(name = "UserRoles",
joinColumns = @JoinColumn(name = "UserId"),
inverseJoinColumns = @JoinColumn(name = "RoleId"))
- public Set<Role> getRoles() { return roles; }
- public void setRoles(Set<Role> roles) { this.roles = roles; }
-}]]>
+ public Set<Role> getRoles() { return roles; }
+ public void setRoles(Set<Role> roles) { this.roles = roles; }
+}
</programlisting>
-<programlisting><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
public class Role {
private Integer roleId;
private String rolename;
@@ -857,7 +857,7 @@
@RoleName
public String getRolename() { return rolename; }
public void setRolename(String rolename) { this.rolename = rolename; }
-}]]>
+}
</programlisting>
</section>
@@ -875,7 +875,7 @@
</imageobject>
</mediaobject>
-<programlisting role="JAVA"><![CDATA[@Entity
+<programlisting language="Java" role="JAVA"><![CDATA[@Entity
public class User {
private Integer userId;
private String username;
@@ -923,7 +923,7 @@
}]]>
</programlisting>
-<programlisting><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
public class Role {
private Integer roleId;
private String rolename;
@@ -948,10 +948,10 @@
@JoinTable(name = "RoleGroups",
joinColumns = @JoinColumn(name = "RoleId"),
inverseJoinColumns = @JoinColumn(name = "GroupId"))
- public Set<Role> getGroups() { return groups; }
- public void setGroups(Set<Role> groups) { this.groups = groups; }
+ public Set<Role> getGroups() { return groups; }
+ public void setGroups(Set<Role> groups) { this.groups = groups; }
-}]]>
+}
</programlisting>
</section>
@@ -1756,7 +1756,7 @@
The following configuration example shows how <literal>LdapIdentityStore</literal> can be configured for an LDAP directory running on fictional host <literal>directory.mycompany.com</literal>. The users are stored within this directory under the <literal>ou=Person,dc=mycompany,dc=com</literal> context, and are identified by the <literal>uid</literal> attribute (which corresponds to their username). Roles are stored in their own context, <literal>ou=Roles,dc=mycompany,dc=com</literal>, and are referenced from the user's entry via the <literal>roles</literal> attribute. Role entries are identified by their common name (the <literal>cn</literal> attribute), which corresponds to the role name. In this example, users can be disabled by setting the value of their <literal>enabled</literal> attribute to <literal>false</literal>.
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:ldap-identity-store
server-address="directory.mycompany.com"
bind-DN="cn=Manager,dc=mycompany,dc=com"
@@ -1800,15 +1800,15 @@
Access the <literal>IdentityManager</literal> either by injecting it into your Seam component, like so:
</para>
-<programlisting role="JAVA"><![CDATA[
- at In IdentityManager identityManager;]]>
+<programlisting language="Java" role="JAVA">
+ at In IdentityManager identityManager;
</programlisting>
<para>
or, through its static <literal>instance()</literal> method:
</para>
-<programlisting role="JAVA"><![CDATA[
-IdentityManager identityManager = IdentityManager.instance();]]>
+<programlisting language="Java" role="JAVA">
+IdentityManager identityManager = IdentityManager.instance();
</programlisting>
<para>
The following table describes <literal>IdentityManager</literal>'s API methods:
@@ -2473,7 +2473,7 @@
The following code listing provides an example set of security rules that grants all <literal>admin</literal> role members access to all Identity Management-related methods:
</para>
-<programlisting><![CDATA[rule ManageUsers
+<programlisting language="Java" role="JAVA">rule ManageUsers
no-loop
activation-group "permissions"
when
@@ -2492,7 +2492,6 @@
then
check.grant();
end
-]]>
</programlisting>
</section>
@@ -2641,19 +2640,19 @@
An empty <literal>@Restrict</literal> implies a permission check of <literal>componentName:methodName</literal>. Take for example the following component method:
</para>
-<programlisting role="JAVA"><![CDATA[@Name("account")
+<programlisting language="Java" role="JAVA">@Name("account")
public class AccountAction {
@Restrict
public void delete() {
...
}
-}]]>
+}
</programlisting>
<para>
In this example, <literal>account:delete</literal> is the implied permission required to call the <literal>delete()</literal> method. This is equivalent to writing <literal>@Restrict("#{s:hasPermission('account','delete')}")</literal>. The following is another example:
</para>
-<programlisting role="JAVA"><![CDATA[@Restrict @Name("account")
+<programlisting language="Java" role="JAVA">@Restrict @Name("account")
public class AccountAction {
public void insert() {
...
@@ -2662,7 +2661,7 @@
public void delete() {
...
}
-}]]>
+}
</programlisting>
<para>
Here, the component class itself is annotated with <literal>@Restrict</literal>. This means that any methods without an overriding <literal>@Restrict</literal> annotation require an implicit permission check. In this case, the <literal>insert()</literal> method requires a permission of <literal>account:insert</literal>, while the <literal>delete()</literal> method requires that the user is a member of the <literal>admin</literal> role.
@@ -2674,14 +2673,14 @@
Being an EL expression, the value of the <literal>@Restrict</literal> annotation may refer to any object within a Seam context. This is extremely useful when checking permissions for a specific object instance. Take the following example:
</para>
-<programlisting role="JAVA"><![CDATA[@Name("account")
+<programlisting language="Java" role="JAVA">@Name("account")
public class AccountAction {
@In Account selectedAccount;
@Restrict("#{s:hasPermission(selectedAccount,'modify')}")
public void modify() {
selectedAccount.modify();
}
-}]]>
+}
</programlisting>
<para>
In this example, the <literal>hasPermission()</literal> function call refers to <literal>selectedAccount</literal>. The value of this variable will be looked up from within the Seam context, and passed to the <literal>hasPermission()</literal> method in <literal>Identity</literal>. This will determine whether the user has the required permissions to modify the specified <literal>Account</literal> object.
@@ -2694,10 +2693,10 @@
It is sometimes necessary to perform a security check in code, without using the <literal>@Restrict</literal> annotation. To do so, use <literal>Identity.checkRestriction()</literal> to evaluate a security expression, like this:
</para>
-<programlisting role="JAVA"><![CDATA[public void deleteCustomer() {
+<programlisting language="Java" role="JAVA">public void deleteCustomer() {
Identity.instance().checkRestriction("#{s:hasPermission(selectedCustomer,
'delete')}");
-}]]>
+}
</programlisting>
<para>
If the specified expression does not evaluate to <literal>true</literal>, one of two exceptions occurs. If the user is not logged in, a <exceptionname>NotLoggedInException</exceptionname> is thrown. If the user is logged in, an <exceptionname>AuthorizationException</exceptionname> is thrown.
@@ -2706,11 +2705,11 @@
You can also call the <literal>hasRole()</literal> and <literal>hasPermission()</literal> methods directly from Java code:
</para>
-<programlisting role="JAVA"><![CDATA[if (!Identity.instance().hasRole("admin"))
+<programlisting language="Java" role="JAVA">if (!Identity.instance().hasRole("admin"))
throw new AuthorizationException("Must be admin to perform this action");
if (!Identity.instance().hasPermission("customer", "create"))
- throw new AuthorizationException("You may not create new customers");]]>
+ throw new AuthorizationException("You may not create new customers");
</programlisting>
</section>
@@ -2725,13 +2724,13 @@
In this section, we will go through some examples of interface security. Say we have a login form that we want rendered only if the user is not already logged in. We can write the following with the <literal>identity.isLoggedIn()</literal> property:
</para>
-<programlisting role="XHTML"><![CDATA[<h:form class="loginForm" rendered="#{not identity.loggedIn}">]]>
+<programlisting language="XML" role="XML"><![CDATA[<h:form class="loginForm" rendered="#{not identity.loggedIn}">]]>
</programlisting>
<para>
If the user is not logged in, the login form will be rendered — very straightforward. Say we also have a menu on this page, and we want some actions to be accessed only by users in the <literal>manager</literal> role. One way you could write this is the following:
</para>
-<programlisting role="XHTML"><![CDATA[<h:outputLink action="#{reports.listManagerReports}"
+<programlisting language="XML" role="XML"><![CDATA[<h:outputLink action="#{reports.listManagerReports}"
rendered="#{s:hasRole('manager')}"> Manager Reports
</h:outputLink>]]>
</programlisting>
@@ -2742,7 +2741,7 @@
A more complex example of conditional rendering might be the following situation: say you have a <literal>h:dataTable</literal> control on a page, and you want to render action links on its records only for users with certain privileges. The <literal>s:hasPermission</literal> EL function lets us use an object parameter to determine whether the user has the necessary permission for that object. A dataTable with secured links might look like this:
</para>
-<programlisting role="XHTML"><![CDATA[<h:dataTable value="#{clients}" var="cl">
+<programlisting language="XML" role="XML"><![CDATA[<h:dataTable value="#{clients}" var="cl">
<h:column>
<f:facet name="header">Name</f:facet>
#{cl.name}
@@ -2768,7 +2767,7 @@
To use page security, you will need a <filename>pages.xml</filename> file. Page security is easy to configure: simply include a <literal><![CDATA[<restrict/>]]></literal> element in the <literal>page</literal> elements that you want to secure. If no explicit restriction is specified in the <literal>restrict</literal> element, access via a non-Faces (GET) request requires an implied <literal>/viewId.xhtml:render</literal> permission, and <literal>/viewId.xhtml:restore</literal> permission is required when any JSF postback (form submission) originates from the page. Otherwise, the specified restriction will be evaluated as a standard security expression. Some examples are:
</para>
-<programlisting role="XML"><![CDATA[<page view-id="/settings.xhtml">
+<programlisting language="XML" role="XML"><![CDATA[<page view-id="/settings.xhtml">
<restrict/>
</page>]]>
</programlisting>
@@ -2776,7 +2775,7 @@
This page requires an implied permission of <literal>/settings.xhtml:render</literal> for non-Faces requests, and an implied permission of <literal>/settings.xhtml:restore</literal> for Faces requests.
</para>
-<programlisting role="XML"><![CDATA[<page view-id="/reports.xhtml">
+<programlisting language="XML" role="XML"><![CDATA[<page view-id="/reports.xhtml">
<restrict>#{s:hasRole('admin')}</restrict>
</page>]]>
</programlisting>
@@ -2794,12 +2793,12 @@
To secure all actions for an entity class, add a <literal>@Restrict</literal> annotation on the class itself:
</para>
-<programlisting role="JAVA"><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
@Name("customer")
@Restrict
public class Customer {
...
-}]]>
+}
</programlisting>
<para>
If no expression is specified in the <literal>@Restrict</literal> annotation, the default action is a permission check of <literal>entity:action</literal>, where the permission target is the entity instance, and the <literal>action</literal> is either <literal>read</literal>, <literal>insert</literal>, <literal>update</literal> or <literal>delete</literal>.
@@ -2833,9 +2832,9 @@
The following example shows how an entity can be configured to perform a security check for any <literal>insert</literal> operations. Note that the method need not perform any action; it is only important that it be annotated correctly:
</para>
-<programlisting role="JAVA"><![CDATA[@PrePersist
+<programlisting language="Java" role="JAVA">@PrePersist
@Restrict
-public void prePersist() {} ]]>
+public void prePersist() {}
</programlisting>
<note>
<title>Using <literal>/META-INF/orm.xml</literal></title>
@@ -2843,7 +2842,7 @@
You can also specify the callback method in <literal>/META-INF/orm.xml</literal>:
</para>
-<programlisting role="XML"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
+<programlisting language="XML" role="XML"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
@@ -2865,7 +2864,7 @@
The following configuration is based on the Seamspace example, and checks if the authenticated user has permission to insert a new <literal>MemberBlog</literal> record. The entity being checked is automatically inserted into the working memory (in this case, <literal>MemberBlog</literal>):
</para>
-<programlisting><![CDATA[rule InsertMemberBlog
+<programlisting language="Java" role="JAVA">rule InsertMemberBlog
no-loop
activation-group "permissions"
when
@@ -2876,7 +2875,7 @@
action == "insert", granted == false)
then
check.grant();
-end;]]>
+end;
</programlisting>
<para>
This rule grants the permission <literal>memberBlog:insert</literal> if the name of the currently authenticated user (indicated by the <literal>Principal</literal> fact) matches that of the member for whom the blog entry is being created. The <literal>principal: Principal()</literal> structure is a variable binding. It binds the instance of the <literal>Principal</literal> object placed in the working memory during authentication, and assigns it to a variable called <literal>principal</literal>. Variable bindings let the variable be referenced in other places, such as the following line, which compares the member name to the <literal>Principal</literal> name. For further details, refer to the JBoss Rules documentation. <!-- #modify: linkme? -->
@@ -2890,7 +2889,7 @@
Security checks for EJB3 entity beans are performed with an <literal>EntityListener</literal>. Install this listener with the following <literal>META-INF/orm.xml</literal> file:
</para>
-<programlisting role="XML"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
+<programlisting language="XML" role="XML"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
@@ -2954,9 +2953,9 @@
To use these annotations, place them on the method or parameter for which you wish to perform a security check. When placed on a method, they specify a target class for which the permission will be checked. Take the following example:
</para>
-<programlisting><![CDATA[
+<programlisting language="Java" role="JAVA">
@Insert(Customer.class)
-public void createCustomer() { ... }]]>
+public void createCustomer() { ... }
</programlisting>
<para>
Here, a permission check will be performed for the user to ensure that they have permission to create new <literal>Customer</literal> objects. The target of the permission check is <literal>Customer.class</literal> (the actual <literal>java.lang.Class</literal> instance itself), and the action is the lower case representation of the annotation name, which in this example is <literal>insert</literal>.
@@ -2965,30 +2964,29 @@
You can annotate a component method's parameters in the same way, as follows. If you do this, you need not specify a permission target, since the parameter value itself will be the target of the permission check.
</para>
-<programlisting><![CDATA[
+<programlisting language="Java" role="JAVA">
public void updateCustomer(@Update Customer customer) {
...
-}]]>
+}
</programlisting>
<para>
To create your own security annotation, just annotate it with <literal>@PermissionCheck</literal>. For example:
</para>
-<programlisting role="JAVA"><![CDATA[@Target({METHOD, PARAMETER})
+<programlisting language="Java" role="JAVA">@Target({METHOD, PARAMETER})
@Documented
@Retention(RUNTIME)
@Inherited
@PermissionCheck
public @interface Promote {
Class value() default void.class;
-}]]>
+}
</programlisting>
<para>
If you wish to override the default permission action name (the lower case version of the annotation name) with another value, you can specify this within the <literal>@PermissionCheck</literal> annotation:
</para>
-<programlisting><![CDATA[@PermissionCheck("upgrade")]]>
-</programlisting>
+<programlisting language="Java" role="JAVA">@PermissionCheck("upgrade")</programlisting>
</section>
<section>
@@ -2997,12 +2995,12 @@
In addition to typsesafe permission annotation support, Seam Security provides typesafe role annotations that let you restrict access to component methods based on the role memberships of the currently authenticated user. Seam provides one such annotation (<literal>org.jboss.seam.annotations.security.Admin</literal>) out of the box. This restricts access of a particular method to users that belong to the <literal>admin</literal> role, as long as such a role is supported by your application. To create your own role annotations, meta-annotate them with <literal>org.jboss.seam.annotations.security.RoleCheck</literal> as in the following example:
</para>
-<programlisting><![CDATA[@Target({METHOD})
+<programlisting language="Java" role="JAVA">@Target({METHOD})
@Documented
@Retention(RUNTIME)
@Inherited
@RoleCheck
-public @interface User { }]]>
+public @interface User { }
</programlisting>
<para>
Any methods subsequently annotated with the <literal>@User</literal> annotation will be automatically intercepted. The user will be checked for membership of the corresponding role name (the lower case version of the annotation name, in this case <literal>user</literal>).
@@ -3232,7 +3230,7 @@
The configuration for <literal>RuleBasedPermissionResolver</literal> requires that a Drools rule base is first configured in <filename>components.xml</filename>. By default, it expects the rule base to be named <literal>securityRules</literal>, as per the following example:
</para>
-<programlisting role="XML"><![CDATA[<components xmlns="http://jboss.com/products/seam/components"
+<programlisting language="XML" role="XML"><![CDATA[<components xmlns="http://jboss.com/products/seam/components"
xmlns:core="http://jboss.com/products/seam/core"
xmlns:security="http://jboss.com/products/seam/security"
xmlns:drools="http://jboss.com/products/seam/drools"
@@ -3259,7 +3257,7 @@
The default rule base name can be overridden by specifying the <literal>security-rules</literal> property for <literal>RuleBasedPermissionResolver</literal>:
</para>
-<programlisting><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:rule-based-permission-resolver
security-rules="#{prodSecurityRules}"/>]]>
</programlisting>
@@ -3277,7 +3275,7 @@
We recommend the Drools documentation when you write your rules file. A simple example of rules file contents is:
</para>
-<programlisting><![CDATA[package MyApplicationPermissions;
+<programlisting language="Java" role="JAVA">package MyApplicationPermissions;
import org.jboss.seam.security.permission.PermissionCheck;
import org.jboss.seam.security.Role;
@@ -3288,7 +3286,7 @@
Role(name == "admin")
then
c.grant();
-end]]>
+end
</programlisting>
<para>
Here, the first thing we see is the package declaration. A package in Drools is a collection of rules. The package name does not relate to anything outside the scope of the rule base, so it can be given any name.
@@ -3306,7 +3304,7 @@
There are two conditions listed in the example LHS. The first condition is:
</para>
-<programlisting><![CDATA[c: PermissionCheck(target == "customer", action == "delete")]]>
+<programlisting language="Java" role="JAVA">c: PermissionCheck(target == "customer", action == "delete")
</programlisting>
<para>
More plainly, this condition states that, to be fulfilled, there must be a <literal>PermissionCheck</literal> object with a <literal>target</literal> property equal to <literal>customer</literal>, and an <literal>action</literal> property equal to <literal>delete</literal> within the working memory.
@@ -3324,8 +3322,7 @@
To return to our simple example, the first line of our LHS is prefixed with <literal>c:</literal>. This is a variable binding, and is used to refer back to the object matching the condition (in this case, the <literal>PermissionCheck</literal>). The second line of the LHS is:
</para>
-<programlisting><![CDATA[Role(name == "admin")]]>
-</programlisting>
+<programlisting language="Java" role="JAVA">Role(name == "admin")</programlisting>
<para>
This condition states that there must be a <literal>Role</literal> object with a <literal>name</literal> of "admin" within the working memory. So, if you are checking for the <literal>customer:delete</literal> permission and the user is a member of the <literal>admin</literal> role, this rule will fire.
</para>
@@ -3333,8 +3330,7 @@
The RHS shows us the consequence of the rule firing:
</para>
-<programlisting><![CDATA[c.grant()]]>
-</programlisting>
+<programlisting language="Java" role="JAVA">c.grant()</programlisting>
<para>
The RHS consists of Java code. In this case it invokes the <literal>grant()</literal> method of the <literal>c</literal> object, which is a variable binding for the <literal>PermissionCheck</literal> object. Other than the <literal>name</literal> and <literal>action</literal> properties of the <literal>PermissionCheck</literal> object, there is also a <literal>granted</literal> property. This is initially set to <literal>false</literal>. Calling <literal>grant()</literal> on a <literal>PermissionCheck</literal> sets the <literal>granted</literal> property to <literal>true</literal>. This means the permission check succeeded, and the user has permission to carry out the action that prompted the permission check.
</para>
@@ -3346,7 +3342,7 @@
So far, we have only looked at permission checks for String-literal permission targets. However, you can also write security rules for more complex permission targets. For example, say you want to write a security rule to allow your users to create blog comments. The following rule shows one way this can be expressed, by requiring that the target of the permission check be an instance of <literal>MemberBlog</literal>, and that the currently authenticated user be a member of the <literal>user</literal> role:
</para>
-<programlisting><![CDATA[rule CanCreateBlogComment
+<programlisting language="Java" role="JAVA">rule CanCreateBlogComment
no-loop
activation-group "permissions"
when
@@ -3357,7 +3353,6 @@
then
check.grant();
end
-]]>
</programlisting>
</section>
@@ -3367,13 +3362,13 @@
It is possible to implement a wildcard permission check (which allows all actions for a given permission target), by omitting the <literal>action</literal> constraint for the <literal>PermissionCheck</literal> in your rule, like so:
</para>
-<programlisting><![CDATA[rule CanDoAnythingToCustomersIfYouAreAnAdmin
+<programlisting language="Java" role="JAVA">rule CanDoAnythingToCustomersIfYouAreAnAdmin
when
c: PermissionCheck(target == "customer")
Role(name == "admin")
then
c.grant();
-end;]]>
+end;
</programlisting>
<para>
This rule allows users with the <literal>admin</literal> role to perform <emphasis>any</emphasis> action for any <literal>customer</literal> permission check.
@@ -3393,7 +3388,7 @@
To use <literal>PersistentPermissionResolver</literal>, you must configure a valid <literal>PermissionStore</literal> in <filename>components.xml</filename>. If this is not configured, the <literal>PersistentPermissionResolver</literal> will attempt to use the default permission store, <xref linkend="security-id_management-jpaidstore" />. To use a permission store other than the default, configure the <literal>permission-store</literal> property as follows:
</para>
-<programlisting><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:persistent-permission-resolver
permission-store="#{myCustomPermissionStore}"/>]]>
</programlisting>
@@ -3583,7 +3578,7 @@
For example, to configure a single entity class to store both user and role permissions:
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:jpa-permission-store
user-permission-class="com.acme.model.AccountPermission"/>]]>
</programlisting>
@@ -3591,7 +3586,7 @@
To configure separate entity classes for storing user and role permissions:
</para>
-<programlisting role="XML"><![CDATA[<security:jpa-permission-store
+<programlisting language="XML" role="XML"><![CDATA[<security:jpa-permission-store
user-permission-class="com.acme.model.UserPermission"
role-permission-class="com.acme.model.RolePermission"/>]]>
</programlisting>
@@ -3710,10 +3705,10 @@
This annotation should be used when the same entity/table stores both user and role permissions. It identifies the property of the entity being used to discriminate between user and role permissions. By default, if the column value contains the string literal <literal>user</literal>, then the record will be treated as a user permission. If it contains the string literal <literal>role</literal>, it will be treated as a role permission. You can also override these defaults by specifying the <literal>userValue</literal> and <literal>roleValue</literal> properties within the annotation. For example, to use <literal>u</literal> and <literal>r</literal> instead of <literal>user</literal> and <literal>role</literal>, write the annotation like so:
-<programlisting role="JAVA"><![CDATA[
+<programlisting language="Java" role="JAVA">
@PermissionDiscriminator(
userValue = "u",
- roleValue = "r")]]>
+ roleValue = "r")
</programlisting>
</para>
</entry>
@@ -3729,7 +3724,7 @@
The following is an example of an entity class that stores both user and role permissions, taken from the Seamspace example.
</para>
-<programlisting role="JAVA"><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
public class AccountPermission implements Serializable {
private Integer permissionId;
private String recipient;
@@ -3781,7 +3776,7 @@
public void setDiscriminator(String discriminator) {
this.discriminator = discriminator;
}
-}]]>
+}
</programlisting>
<para>
Here, the <literal>getDiscriminator()</literal> method has been annotated with <literal>@PermissionDiscriminator</literal>, to allow <literal>JpaPermissionStore</literal> to determine which records represent user permissions and which represent role permissions. The <literal>getRecipient()</literal> method is annotated with both <literal>@PermissionUser</literal> and <literal>@PermissionRole</literal>. This means that the <literal>recipient</literal> property of the entity will either contain the name of the user or the name of the role, depending on the value of the <literal>discriminator</literal> property.
@@ -3860,13 +3855,13 @@
The following shows the above annotations in use. They can also be seen in the SeamSpace example.
</para>
-<programlisting role="JAVA"><![CDATA[@Permissions({
+<programlisting language="Java" role="JAVA">@Permissions({
@Permission(action = "view"),
@Permission(action = "comment")
})
@Entity
-public class MemberImage implements Serializable {...}]]>
+public class MemberImage implements Serializable {...}
</programlisting>
<para>
This example demonstrates how two allowable permission actions, <literal>view</literal> and <literal>comment</literal> can be declared for the entity class <literal>MemberImage</literal>.
@@ -3882,13 +3877,13 @@
For example, if recipient "Bob" is granted both the <literal>view</literal> and <literal>comment</literal> permissions for a particular <literal>MemberImage</literal> (an entity bean) instance, then by default the <literal>action</literal> property of the permission entity will contain "<literal>view,comment</literal>", representing the two granted permission actions. Or, if you are using bitmasked values defined as follows:
</para>
-<programlisting role="JAVA"><![CDATA[@Permissions({
+<programlisting language="Java" role="JAVA">@Permissions({
@Permission(action = "view", mask = 1),
@Permission(action = "comment", mask = 2)
})
@Entity
-public class MemberImage implements Serializable {...}]]>
+public class MemberImage implements Serializable {...}
</programlisting>
<para>
The <literal>action</literal> property will contain "3" (with both the 1 bit and 2 bit switched on). For a large number of allowable actions for any particular target class, the storage required for the permission records is greatly reduced by using bitmasked actions.
@@ -3909,10 +3904,10 @@
The <literal>IdentifierStrategy</literal> interface is very simple, declaring only two methods:
</para>
-<programlisting role="JAVA"><![CDATA[public interface IdentifierStrategy {
+<programlisting language="Java" role="JAVA">public interface IdentifierStrategy {
boolean canIdentify(Class targetClass);
String getIdentifier(Object target);
-}]]>
+}
</programlisting>
<para>
The first method, <literal>canIdentify()</literal>, returns <literal>true</literal> if the identifier strategy is capable of generating a unique identifier for the specified target class. The second method, <literal>getIdentifier()</literal>, returns the unique identifier value for the specified target object.
@@ -3931,22 +3926,21 @@
This identifier strategy generates unique identifiers for classes, and uses the value of the <literal>name</literal> (if specified) in the <literal>@Identifier</literal> annotation. If no <literal>name</literal> property is provided, the identifier strategy attempts to use the component name of the class (if the class is a Seam component). It will create an identifier based on the class name (excluding the package name) as a last resort. For example, the identifier for the following class will be <literal>customer</literal>:
</para>
-<programlisting role="JAVA"><![CDATA[@Identifier(name = "customer")
-public class Customer {...}]]>
+<programlisting language="Java" role="JAVA">@Identifier(name = "customer")
+public class Customer {...}
</programlisting>
<para>
The identifier for the following class will be <literal>customerAction</literal>:
</para>
-<programlisting role="JAVA"><![CDATA[@Name("customerAction")
-public class CustomerAction {...}]]>
+<programlisting language="Java" role="JAVA">@Name("customerAction")
+public class CustomerAction {...}
</programlisting>
<para>
Finally, the identifier for the following class will be <literal>Customer</literal>:
</para>
-<programlisting><![CDATA[public class Customer {...} ]]>
-</programlisting>
+<programlisting language="Java" role="JAVA">public class Customer {...} </programlisting>
</section>
<section>
@@ -3955,14 +3949,14 @@
This identifier strategy generates unique identifiers for entity beans. It concatenates the entity name (or otherwise configured name) with a string representation of the primary key value of the entity. The rules for generating the name section of the identifier are similar to those in <literal>ClassIdentifierStrategy</literal>. The primary key value (that is, the entity ID) is obtained with the <literal>PersistenceProvider</literal> component, which can determine the value regardless of the persistence implementation being used in the Seam application. For entities not annotated with <literal>@Entity</literal>, you must explicitly configure the identifier strategy on the entity class itself, like this:
</para>
-<programlisting role="JAVA"><![CDATA[@Identifier(value = EntityIdentifierStrategy.class)
-public class Customer {...} ]]>
+<programlisting language="Java" role="JAVA">@Identifier(value = EntityIdentifierStrategy.class)
+public class Customer {...}
</programlisting>
<para>
Assume we have the following entity class:
</para>
-<programlisting role="JAVA"><![CDATA[@Entity
+<programlisting language="Java" role="JAVA">@Entity
public class Customer {
private Integer id;
private String firstName;
@@ -3979,13 +3973,13 @@
public String getLastName() { return lastName; }
public void setLastName(String lastName) { this.lastName = lastName; }
-}]]>
+}
</programlisting>
<para>
For a <literal>Customer</literal> instance with an <literal>id</literal> value of <literal>1</literal>, the value of the identifier would be <literal>Customer:1</literal>. If the entity class is annotated with an explicit identifier name, like so:
</para>
-<programlisting role="JAVA"><![CDATA[@Entity @Identifier(name = "cust")
+<programlisting language="Java" role="JAVA"><![CDATA[@Entity @Identifier(name = "cust")
public class Customer {...}]]>
</programlisting>
<para>
@@ -4010,7 +4004,7 @@
The <literal>PermissionManager</literal> component is an application-scoped Seam component that provides a number of permission-management methods. It must be configured with a permission store before use. By default, it will attempt to use <literal>JpaPermissionStore</literal>. To configure a custom permission store, specify the <literal>permission-store</literal> property in <filename>components.xml</filename>:
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<security:permission-manager permission-store="#{ldapPermissionStore}"/>]]>
</programlisting>
<para>
@@ -4312,13 +4306,13 @@
Seam includes basic support for serving sensitive pages via the HTTPS protocol. To configure this, specify a <literal>scheme</literal> for the page in <filename>pages.xml</filename>. The following example shows how the view <filename>/login.xhtml</filename> can be configured to use HTTPS:
</para>
-<programlisting role="XML"><![CDATA[<page view-id="/login.xhtml" scheme="https"/>]]>
+<programlisting language="XML" role="XML"><![CDATA[<page view-id="/login.xhtml" scheme="https"/>]]>
</programlisting>
<para>
This configuration automatically extends to both <literal>s:link</literal> and <literal>s:button</literal> JSF controls, which (when specifying the <literal>view</literal>) will render the link under the correct protocol. Based on the previous example, the following link will use the HTTPS protocol because <filename>/login.xhtml</filename> is configured to use it:
</para>
-<programlisting role="XHTML"><![CDATA[<s:link view="/login.xhtml" value="Login"/>]]>
+<programlisting language="XML" role="XML"><![CDATA[<s:link view="/login.xhtml" value="Login"/>]]>
</programlisting>
<para>
If a user browses directly to a view with the incorrect protocol, a redirect is triggered, and the same view will be reloaded with the correct protocol. For example, browsing to a <literal>scheme="https"</literal> page with HTTP triggers a redirect to the same page using HTTPS.
@@ -4327,7 +4321,7 @@
You can also configure a <emphasis>default scheme</emphasis> for all pages. This is useful if you only want to use HTTPS for a few pages. If no default scheme is specified, the current scheme will be used. So, once the user accesses a page requiring HTTPS, then HTTPS continues to be used after the user has navigated to other non-HTTPS pages. This is good for security, but not for performance. To define HTTP as the default <literal>scheme</literal>, add this line to <filename>pages.xml</filename>:
</para>
-<programlisting role="XML"><![CDATA[<page view-id="*" scheme="http" />]]>
+<programlisting language="XML" role="XML"><![CDATA[<page view-id="*" scheme="http" />]]>
</programlisting>
<para>
If <emphasis>none</emphasis> of the pages in your application use HTTPS, you need not define a default scheme.
@@ -4336,7 +4330,7 @@
You can configure Seam to automatically invalidate the current HTTP session each time the scheme changes. To do so, add this line to <literal>components.xml</literal>:
</para>
-<programlisting role="XML"><![CDATA[<web:session invalidate-on-scheme-change="true"/>]]>
+<programlisting language="XML" role="XML"><![CDATA[<web:session invalidate-on-scheme-change="true"/>]]>
</programlisting>
<para>
This option offers more protection from session ID sniffing and sensitive data leakage from pages using HTTPS to pages using HTTP.
@@ -4347,7 +4341,7 @@
If you wish to configure the HTTP and HTTPS ports manually, you can do so in <filename>pages.xml</filename> by specifying the <literal>http-port</literal> and <literal>https-port</literal> attributes on the <literal>pages</literal> element:
</para>
-<programlisting role="XML"><![CDATA[
+<programlisting language="XML" role="XML"><![CDATA[
<pages xmlns="http://jboss.com/products/seam/pages"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.2.xsd"
@@ -4370,7 +4364,7 @@
To use CAPTCHA, you need to configure the Seam Resource Servlet, which provides your pages with CAPTCHA challenge images. Add the following to <filename>web.xml</filename>:
</para>
-<programlisting role="XML"><![CDATA[<servlet>
+<programlisting language="XML" role="XML"><![CDATA[<servlet>
<servlet-name>Seam Resource Servlet</servlet-name>
<servlet-class>org.jboss.seam.servlet.SeamResourceServlet</servlet-class>
</servlet>
@@ -4388,7 +4382,7 @@
It is easy to add a CAPTCHA challenge to a form:
</para>
-<programlisting role="XHTML"><![CDATA[<h:graphicImage value="/seam/resource/captcha"/>
+<programlisting language="XML" role="XML"><![CDATA[<h:graphicImage value="/seam/resource/captcha"/>
<h:inputText id="verifyCaptcha" value="#{captcha.response}"
required="true">
<s:validate />
@@ -4406,7 +4400,7 @@
You can customize the CAPTCHA algorithm by overriding the built-in component:
</para>
-<programlisting role="JAVA"><![CDATA[@Name("org.jboss.seam.captcha.captcha")
+<programlisting language="Java" role="JAVA">@Name("org.jboss.seam.captcha.captcha")
@Scope(SESSION)
public class HitchhikersCaptcha extends Captcha
{
@@ -4422,7 +4416,7 @@
img.getGraphics().drawOval(5, 3, 60, 14); //add an obscuring decoration
return img;
}
-}]]>
+}
</programlisting>
</section>
@@ -4587,13 +4581,13 @@
The following code demonstrates <literal>RunAsOperation</literal> usage. The <literal>addRole()</literal> method is called to provide a set of roles to 'borrow' for the duration of the operation. The <literal>execute()</literal> method contains the code that will be executed with the elevated privileges.
</para>
-<programlisting role="JAVA"><![CDATA[
+<programlisting language="Java" role="JAVA">
new RunAsOperation() {
public void execute() {
executePrivilegedOperation();
}
}.addRole("admin")
- .run();]]>
+ .run();
</programlisting>
<para>
Similarly, the <literal>getPrincipal()</literal> or <literal>getSubject()</literal> methods can also be overriden to specify the <literal>Principal</literal> and <literal>Subject</literal> instances to use for the duration of the operation. Finally, the <literal>run()</literal> method is used to carry out the <literal>RunAsOperation</literal>.
@@ -4606,7 +4600,7 @@
If your application has special security requirements, you may need to extend your Identity component. The following example shows an Identity component extended with an additional <literal>companyCode</literal> field to handle credentials. (Usually this would be handled by a <literal>Credentials</literal> component.) The install precendence of <literal>APPLICATION</literal> ensures that this extended Identity is installed instead of the built-in Identity.
</para>
-<programlisting role="JAVA"><![CDATA[@Name("org.jboss.seam.security.identity")
+<programlisting language="Java" role="JAVA">@Name("org.jboss.seam.security.identity")
@Scope(SESSION)
@Install(precedence = APPLICATION)
@BypassInterceptors
@@ -4630,7 +4624,7 @@
log.info("###### CUSTOM LOGIN CALLED ######");
return super.login();
}
-}]]>
+}
</programlisting>
<warning>
<para>
@@ -4664,7 +4658,7 @@
OpenID processing requires the <literal>OpenIdPhaseListener</literal>, which should be added to your <filename>faces-config.xml</filename> file. The phase listener processes the callback from the OpenID provider, allowing re-entry into the local application.
</para>
-<programlisting role="XML"><![CDATA[<lifecycle>
+<programlisting language="XML" role="XML"><![CDATA[<lifecycle>
<phase-listener>
org.jboss.seam.security.openid.OpenIdPhaseListener
</phase-listener>
@@ -4681,7 +4675,7 @@
To initiate an OpenID login, present a form to the user requesting the user's OpenID. The <literal>#{openid.id}</literal> value accepts the user's OpenID and the <literal>#{openid.login}</literal> action initiates an authentication request.
</para>
-<programlisting role="XML"><![CDATA[<h:form>
+<programlisting language="XML" role="XML"><![CDATA[<h:form>
<h:inputText value="#{openid.id}" />
<h:commandButton action="#{openid.login}" value="OpenID Login"/>
</h:form>]]>
@@ -4697,7 +4691,7 @@
The simplest strategy is to simply log the user in immediately. The following navigation rule shows how to handle this using the <literal>#{openid.loginImmediately()}</literal> action.
</para>
-<programlisting role="XML"><![CDATA[<page view-id="/openid.xhtml">
+<programlisting language="XML" role="XML"><![CDATA[<page view-id="/openid.xhtml">
<navigation evaluate="#{openid.loginImmediately()}">
<rule if-outcome="true">
<redirect view-id="/main.xhtml">
@@ -4730,7 +4724,7 @@
Logging out (forgetting an OpenID association) is done by calling <literal>#{openid.logout}</literal>. You can call this method directly if you are not using Seam Security. If you are using Seam Security, you should continue to use <literal>#{identity.logout}</literal> and install an event handler to capture the logout event, calling the OpenID logout method.
</para>
-<programlisting role="XML"><![CDATA[<event type="org.jboss.seam.security.loggedOut">
+<programlisting language="XML" role="XML"><![CDATA[<event type="org.jboss.seam.security.loggedOut">
<action execute="#{openid.logout}" />
</event>]]>
</programlisting>
More information about the jboss-cvs-commits
mailing list