You declare assembly−descriptor as the last child of the ejb−jar element — after the enterprise−beans element in which you have so far been placing all your...

Pokaż mi serce nie opętane zwodniczymi marzeniami, a pokażę ci człowieka szczęśliwego.

..
</enterprise−beans>
<assembly−descriptor>
...
</assembly−descriptor>
</ejb−jar>
The assembly−descriptor element starts by listing all the security−role elements. Each declaration of the security−role covers exactly one role in the bean. So, if you need 20 roles, 20 declarations of security−role will exist.
Tip The security roles defined by the security−role elements are scoped to the ejb−jar file level, and apply to all the enterprise beans in the ejb−jar file. If you have two JAR files that nominate the same roles, they are treated as independent entities as far as the container is concerned.
Inside the security−role element is only one required tag — the name of the role being declared:
<assembly−descriptor>
<security−role>
<role−name>customer_servlet</role−name>
</security−role>
420
Chapter 17: Using Advanced EJB Techniques
</assembly−descriptor>
Tip
You can add a description string with each role's name, just as you can with most other items in the deployment descriptor.
Declaring role names is just the first step. It is a declaration of who might want to use the system for the deployment tool to look at in order to start putting things in order. The next step is to assign a role to an individual bean to be used when no other information is known about the caller (that is, when no role information is present yet).
Forcing a bean to run as a particular user
To define information about the default security information for a bean, we now jump back to the deployment−descriptor declarations dealing with a specific bean instance (such as entity or session elements).
When declaring user information for a bean, you have two options: provide a specific role name to run under every time, or always use whatever the caller provides. The choice here is binary — you can't provide both paths. In either case, you start by specifying the security−identity element. The new element is placed between the primkey−field and query elements if you are using an entity bean, and after the transaction−type element if you are using a session bean, as shown in the following example:
<enterprise−beans>
<entity>
...
<primkey−field>OrderID</primkey−field>
<security−identity>
???
</security−identity>
<query>
...
</query>
</entity>
<session>
...
<transaction−type>Container</transaction−type>
<security−identity>
???
</security−identity>
</session>
</enterprise−beans>
security−identity has one of two children elements: run−as or use−caller−identity. As the names suggest, these control either a role name to be used by the bean, or a direction in which to use the caller's identity information.
For the former case, you provide a role−name element as the child that declares the role that should be used.
The name here must be one of the names that you have just declared in the security−role section:
<security−identity>
<run−as>
<role−name>servlet_customer</role−name>
</run−as>
</security−identity>
In order to use caller identity, you need only the empty element declaration. The rest is assumed from the runtime context.
421
Chapter 17: Using Advanced EJB Techniques
<security−identity>
<use−caller−identity/>
</security−identity>
Note Message−driven beans do not permit the use of use−caller−identity semantics. The deployment tool should flag an error if you declare them.
Nominating security information