Seam security framework-Authorization (translation) (2)

15.6.4. Protect the page

Page security requires the application to usepages.xmlFile, and it is very easy to configure. It's just that you need to protectpageElement contains<restrict/>Element. IfrestrictThe element does not explicitly specify a limit. When a non-faces (GET) request is sent to access the page, the implicit permission is checked./viewId.xhtml:renderAnd any JSF postback (Form submission) originating from the page requires permissions./viewId.xhtml:restore. Otherwise, the specified restriction will be evaluated as a standard security expression. Here are two examples:

<Page view-id = "/settings.xhtml">
<Restrict/>
</Page>

This page implies a permission license for the non-faces request:/settings.xhtml:renderAnd an implicit permission license for the faces request:/settings.xhtml:restore.

<Page view-id = "/reports.xhtml">
<Restrict >#{ s: hasRole ('admin')} </restrict>
</Page>

To access the faces and non-faces requests on this page, the user must beadminOne of the roles.

15.6.5. Protecting entities

Seam security also makes it possible to apply security restrictions on reading, inserting, updating, and deleting entities.

To protect all actions of the object class, you must add@RestrictNote:

@ Entity
@ Name ("customer ")
@ Restrict
Public class Customer {

}

If@RestrictIf no expression is specified in the comment, the default security check isentity:actionPermission check. The target permission is an object instance, andactionYesRead),Insert),Update)OrDelete).

You may also place the @ Restrict Annotation on the method of the object lifecycle (the annotation is described below), but only Restrict some actions:

• @PostLoad-Called after the entity instance is loaded from the database. ConfigurereadLicense.

• @PrePersist-Called before inserting a new instance of an object. ConfigureinsertLicense.

• @PreUpdate-Called before object update. ConfigureupdateLicense.

• @PreRemove-Called before object deletion. ConfiguredeleteLicense.

Here is an example to illustrate how the object method is configuredinsertPerform Security check for the operation. Note that this method does not need to do anything. The only important thing about security is how it is annotated:

@ PrePersist @ Restrict
Public void prePersist () {} Use /META-INF/orm.xml

You can also/META-INF/orm.xmlSpecify a callback method:

<? 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 = "http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
Version = "1.0">

<Entity class = "Customer">
<Pre-persist method-name = "prePersist"/>
</Entity>

</Entity-mappings>

Of course, you still need@RestrictOfCustomerAnnotationsprePersist()Method.

Here is a check that the verified user is allowed to insert a newMemberBlogExample of object permission rules recorded (from the seamspace example. The security check object is automatically inserted into the working memory (in this exampleMemberBlog):

Rule InsertMemberBlog
No-loop
Activation-group "permissions"
When
Principal: Principal ()
MemberBlog: MemberBlog (member: member-> (member. getUsername (). equals (principal. getName ())))
Check: PermissionCheck (target = memberBlog, action = "insert", granted = false)
Then
Check. grant ();
End;

If the user is verifiedPrincipalSpecifies) if the user name is the same as that of the member who created the blog entry, the rule will grant the user the permission.memberBlog:insert. You can see in the sample code"principal: Principal()"Structure is a bound variable, which is bound toPrincipalAnd the variable name is assignedprincipal. Variable binding allows its value to be referenced elsewhere. For example, the username andPrincipal. For more details, see the JBoss Rules document.

Finally, we need to install a listener to integrate Seam security with your JPA provider.

15.6.5.1. Using JPA for Entity security

Use oneEntityListenerTo check the security of the EJB3 Entity Bean. You can use the followingMETA-INF/orm.xmlFile to install this listener:

<? 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 = "http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_1_0.xsd"
Version = "1.0">

<Persistence-unit-metadata>
<Persistence-unit-defaults>
<Entity-listeners>
<Entity-listener class = "org. jboss. seam. security. EntitySecurityListener"/>
</Entity-listeners>
</Persistence-unit-defaults>
</Persistence-unit-metadata>

</Entity-mappings> 15.6.5.2. entity security using a manageable Hibernate session

If you use a HibernateSessionFactoryAnd uses annotations, ororm.xmlFile, so you can use object security without any special operations.
15.6.6. type security permission comment

Seam provides some functions@RestrictReplace comments. These comments provide security benefits during compilation because they are not@RestrictIn this way, any EL expression is supported.

Out-of-the-box, Seam has standard CRUD-based comments, and adding your own comments is just a simple problem. The following comments are:org.jboss.seam.annotations.securityPackage:

• @ Insert

• @ Read

• @ Update

• @ Delete

To use these annotations, you just need to put them in the methods and parameters you want to perform the security check. If they are placed on methods, they should specify a target class that will check the permissions. For example:

@ Insert (Customer. class)
Public void createCustomer (){

}

In this example, the permission check is executed to ensure that the user creates a newCustomerObject Right. The purpose of permission check isCustomer.class(Actuallyjava.lang.ClassInstance itself), and the action is the lowercase value of the annotation name. In this exampleinsert.

You can also annotate the parameters of component methods in the same way. If it is commented out in this way, it does not need to specify a permission target (the parameter value itself is the target of the permission check ):

Public void updateCustomer (@ Update Customer customer Customer ){

}

To create your own security comments, you only need to use@PermissionCheckAnnotations, for example:

@ Target ({METHOD, PARAMETER })
@ Brief ented
@ Retention (RUNTIME)
@ Inherited
@ PermissionCheck
Public @ interface Promote {
Class value () default void. class;
}

If you want to use other values to reload the default permission action name (lower-case comment name), you should@PermissionCheckSpecified in the comment:

@ PermissionCheck ("upgrade") 15.6.7. Type-safe role comment

In addition to permission annotations for type security, Seam security also provides role annotations for type security. These annotations allow you to restrict access to component methods based on the current role relationship to verify users. Seam provides such an out-of-the-box comment,org.jboss.seam.annotations.security.Admin, Which is used to limitadminOnly one member can access a method. To create your own role annotations, you can simply useorg.jboss.seam.annotations.security.RoleCheckMeta annotation, as shown in the following example:

@ Target ({METHOD })
@ Brief ented
@ Retention (RUNTIME)
@ Inherited
@ RoleCheck
Public @ interface User {
}

Any@UserThe annotation method will be automatically intercepted and check whether the user is in the relationship with the corresponding role name (in this exampleuser).