javaee / ejb-spec

See javax.ejb project for API. Contains legacy issues only.
https://github.com/javaee/javax.ejb
6 stars 1 forks source link

Remove restriction on definition of a security-role withing the ejb deployment descriptor, as an implicit declaration of a corresponding security-role-reference for the role #101

Closed glassfishrobot closed 11 years ago

glassfishrobot commented 11 years ago

From Ron Monzillo:

the ejb spec requires that role references be declared either by annotation (@DeclareRole or @RolesAllowed) or by security-role-ref within the ejb deployment descriptor. The ejb spec does not consider the definition of a security-role withing the ejb deployment descriptor, as an implicit declaration of a corresponding security-role-reference for the role (given that the role-reference has not otherwise been declared).

I recall that during a prior release of EJB, we had taken steps to adopt an ease of use feature from Servlet; which eliminated the need for developers to declare security-role-refs for cases where the intent is to reference a role using the same reference value as the name of the role.

It looks like EJB approximated that simplification, but as I wrote above, does not go so far as to implicitly declare security-role-refs for roles declared only as a result of their definition in a security-role element in the ejb deployment descriptor. Servlet's simplification also includes that case, and as a result, Servlet developers only need to declare role reference when only using annotations, or when they need to remap a role-reference to some other role. Conversely EJB application developers must always declare security role refs either by annotation or in the ejb deployment descriptor; since role references are not inferred from security role declarations in the ejb deployment descriptor.

Affected Versions

[3.2]

glassfishrobot commented 11 years ago

Reported by mvatkina

glassfishrobot commented 11 years ago

mvatkina said: Proposed changes (by Ron):

In Section 12.2.5.3 Declaration of Security Roles Referenced from the Bean’s Code

split 1st para into 2 as follows:

The Bean Provider is responsible for declaring all names that may be used to reference security roles from the enterprise bean code. The names of security-roles defined in the deployment descriptor, or used in the RolesAllowed annotation are implicitly declared. The Bean provider is responsible for using either the DeclareRoles annotation or the security-role-ref element to declare all such names that are not implicitly declared.

The DeclareRoles annotation is specified on a bean class, where it serves to declare the names of (otherwise undeclared) roles that may be tested by calling isCallerInRole from within the methods of the annotated class. Declaring the security roles allows the Bean Provider, Application Assembler, or Deployer to link security role names used in the code to the security roles defined for an assembled application. In the absence of this linking step, any security role name as used in the code will be assumed to correspond to a security role of the same name.

retain the original 2nd para with changes as follows:

When the Bean Provider uses the DeclareRoles annotation to declare the name of a role used as a parameter to the isCallerInRole(String roleName) method, the declared name must be the same as the parameter value. The Bean Provider may optionally provide a description of the named security roles in the description element of the DeclareRoles annotation.

retain original 3rd paragraph, and the 1st example unchanged

retain the original 4th paragraph with the following changes:

The Bean Provider must use the security-role-ref elements of the deployment descriptor to declare any security roles referenced in the code and not otherwise declared. The security-role-ref elements are defined as follows:

retain the rest of the section unchanged

Change section 12.3.3 Linking Security Role References to Security Roles to contain the following 3 paragraphs

The application's references to security roles are linked to the security roles defined for the application. In the absence of any explicit linking, a security role reference will be linked to a security role having the same name. This requirement also applies to role references with value “”, and an explicit mapping should only be defined for a role reference with value “ when the reference needs to be linked to an application role with name other than “**”.

The Application Assembler uses a security-role-ref element to explicitly link a role reference by a component to a security role defined by annotation and/or by security-role element (as described in section 12.3.1). The linkage is made explicit using the role-link element of the security-role-ref element; in which case the value of the role-link element must be the name of one of the security roles defined by annotation and/or security-role element.

A security-role-ref element need not be defined for a role reference that is to be mapped to a security-role with the same name as the role reference, and when a role-link is not specified within a security-role-ref, the reference is implicitly mapped to the security role with the same name as the reference.

Some other things to fix:

Replace the 3rd para pf section 12.3.2.1 12.3.2.1 Specification of Method Permissions with Metadata Annotations with the following:

The RolesAllowed, PermitAll, and DenyAll annotations are used to specify method permissions. The value of the RolesAllowed annotation is a list of security role names to be mapped to the security roles that are permitted to execute the specified method(s). The PermitAll annotation specifies that all security roles, including any unauthenticated roles, are permitted to execute the specified method(s). The DenyAll annotation specifies that no security roles, including any unauthenticated roles, are permitted to execute the specified method(s).

Replace the 4th para of section 12.3.2.2 Specification of Method Permissions in the Deployment Descriptor with the following:

The Bean Provider or Application Assembler can indicate that all roles, including any unauthenticated roles, are permitted to execute one or more specified methods (i.e., the methods should not be “checked” for authorization prior to invocation by the container). The unchecked element is used instead of a role name in the method-permission element to indicate that all roles, including any unauthenticated roles, are permitted.

glassfishrobot commented 11 years ago

mvatkina said: Updated the text as above in rev 55.

glassfishrobot commented 11 years ago

Was assigned to mvatkina

glassfishrobot commented 7 years ago

This issue was imported from java.net JIRA EJB_SPEC-101

glassfishrobot commented 11 years ago

Marked as fixed on Friday, March 29th 2013, 6:19:15 pm