SCBCD-Security Management

1)Assuming that ctx is a reference to the SessionContext, which of the following statements can be used to check whether the caller has a role of "manager"?

1)ctx.isUserInRole("manager")
2)ctx.isCallerInRole("manager")
3)ctx.getCallerPrincipal("manager")

2)Which of the following statements regarding EJB security are true? [Select all correct answers]

1)A security role or a method can only appear once in a method-permission element.
2)A security role or a method may appear in multiple method-permission elements.
3)The Application Assembler uses the unchecked element instead of a role name in the method-permission element to indicate that a method should not be checked for authorization.
4)If a security role is defined but not used in any method-permission elements that role has permission over all methods of any EJBs within the Enterprise Javabean application.

3)Which one of the following is a responsibility of the EJB Container with regards to EJB security?

1)The EJB Container is required to provide a security domain and one or more principal realms to the enterprise bean's.
2)The EJB Container is required to provide tools for the Bean provider to allow them to debug enterprise bean's once they have been deployed.
3)The EJB Container is required to link security role references to security roles.
4)The EJB Container is responsible for configuring the principal delegation for inter-component calls.

4)The exhibit excerpt is from a container managed persistence entity bean, which one of the following statements is correct?

...
public void ejbActivate() {
   try{
      // get the caller principal
      Principal callerPrincipal = myEntityCtx.getCallerPrincipal();
      // get the distinguished name from the principal
      log(callerPrincipal.getName());
   } catch(Throwable t) {
      //Oooops!!
   }
}
...

1)There will be an entry in the log with the return value from callerPrincipal.getName().
2)There will not be an entry in the log as the code will not execute  log(callerPrincipal.getName()).
3)There will be an entry in the log of "null".
4)This code will not compile as the method getCallerPrincipal() on the javax.ejb.EntityContext returns a boolean result not a reference to an instance of java.security.Principal.

5)Based on the exhibit which of the following statements is correct? [Select all correct answers]

...
<method-permission>
   <role-name>Manager</role-name>
   <method>
      <ejb-name>ProductCatalogService</ejb-name>
      <method-intf>Home</method-intf>
      <method-name>create</method-name>
   </method>
</method-permission>
<method-permission>
   <role-name>Secretary</role-name>
   <method>
      <ejb-name>ProductCatalogService</ejb-name>
      <method-intf>Remote</method-intf>
      <method-name>create</method-name>
   </method>
</method-permission>
...

1)A caller with the role of Secretary is guaranteed to have permission to use the method create on the ProductCatalogService's Home interface.
2)A caller with the role of Manager is guaranteed to have permission to use the method create on the ProductCatalogService's Home interface.
3)A caller with the role of Boss is guaranteed to have permission to use the method create on the ProductCatalogService's Home interface and the method create on the ProductCatalogService's Remote interface.
4)A caller with the role of Secretary is guaranteed to have permission to use the method create on the ProductCatalogService's Remote interface.

6)Which of the following are responsibilities of the Application Assembler? [Select all correct answers]

1)The Application Assembler should hard-code security policies in the enterprise bean's business methods
2)The Application Assembler is responsible for defining security roles in the deployment descriptor.
3)The Application Assembler assigns principals (such as individual users) used for managing security in the operational environment to the security roles defined in the security-role elements of the deployment descriptor.
4)The Application Assembler is responsible for defining method permissions.

7)Identify responsibilities for the EJB deployer from the options below? [Select all correct answers]

1)Along with the Application Assembler define the appropriate security policies for the application.
2)Setting up the appropriate security policy for the enterprise bean application.
3)Along with the System Administrator setting up of the principal delegation in a Container-specific way.
4)Describe all the requirements for the caller's principal management of inter-enterprise bean invocations as part of the description.

8)Which of the following are available within EJB security management? [Select all correct answers]

1)Declarative security does not allow you to specify that the Local interface's version of a method is accessible, but that the Remote interface's version of the method is not accessible to anyone.
2)Using declarative security you can specify that you do not want anyone to have access to methods of your bean.
3)Using declarative security it is possible to specify that the caller of a bean will appear to be running as a different role for calls that are made from that bean to other bean.
4)EJB security management means that users of EJBs must change their passwords and usernames on a frequent basis.

9)Type in the tag name (without opening and closing braces) that allows you to assign the role required to have access to an EJB method. ______

10)Please select the following statements that correctly describe EJB support for security management? [Select all correct answers]

1)Authorisation to invoke a bean's method can be defined at a bean's method level.
2)Authorisation to invoke a bean's method can be defined at the bean instance level using tags within the deployment descriptor.
3)Authorisation to invoke a bean's method cannot be controlled. EJB supports only authentication which is controlled through the deployment descriptor.
4)Authorisation to invoke a bean's method can be controlled using either programmatic security or declaratively.

Answers:

1)2

Answer 1 is incorrect because the method isUserInRole(...) does not exist on the javax.ejb.SessionContext interface.

Answer 2 is correct as it uses the javax.ejb.SessionContext.isCallerInRole(...) method. Bean code can use the javax.ejb.SessionContext.isCallerInRole(String roleName) method to test whether the current caller has been assigned to a given security role. Security roles are defined by the Application Assembler in the deployment descriptor and are assigned to principals or principal groups that exist in the operational environment by the Deployer. The Bean Provider is responsible for declaring all the security role names used in the enterprise bean code in the security-role-ref elements of the deployment descriptor.

Answer 3 is incorrect as it uses the javax.ejb.SessionContext.getCallerPrincipal method. This does not return a boolean, but instead returns the Security Principal object of the caller.

2)2,3

Answer 2 and 3 are correct.

A security role or a method may appear in multiple method permission elements. Method permission elements allow the application assembler to specify the methods of the home and component interfaces that each security role is allowed to invoke.

Using unchecked ensures that the container will not make authorisation checks prior to invocation of the specified operation. If a method relation specifies both the unchecked element for a method and also a security role, the method will not be checked for authorization.

If a security role is defined but not used in any method-permission elements it does not mean that the role has permission to invoke all methods. A caller with this role will have the same rights as a caller without a specified security role.

3)1

Answer 1 is correct, the EJB Container provides a security domain and one or more principal realms to the enterprise beans. The EJB architecture does not specify how an EJB Server should implement a security domain, and does not define the scope of a security domain. A security domain can be implemented, managed, and administered by the EJB Server. The EJB Server can, but is not required to, provide support for multiple security domains, and/or multiple principal realms.

Answer 2 is incorrect, although EJB Containers may provide these sorts of facilities, it is not required that EJB Containers provide this feature.

Answer 3 is incorrect, this is a responsibility of the Application Assembler. If the Application Assembler defines the security-role elements in the deployment descriptor, they are also responsible for linking all the security role references declared in the security-role-ref elements to the security roles defined in the security-role elements. The Application Assembler links each security role reference to a security role using the role-link element. The value of the role-link element must be the name of one of the security roles defined in a security-role element.

Answer 4 is incorrect, this is a responsibility of the Deployer. With regards to principal delegation the Deployer must follow any instructions supplied by the Application Assembler which could be in the run-as elements of the deployment descriptor, in the description elements of the deployment descriptor, or in a deployment manual.

4)2

Answer 1 is incorrect, the code will not reach that line of code.

Answer 2 is correct, this is the ejbActivate method of an entity bean. The container invokes the ejbActivate() method on an instance, when an instance needs to be activated to service an invocation on an existing entity object. This occurs because there is no suitable instance in the ready state to service the client's call. The getCallerPrincipal() method returns the java.security.Principal that identifies the invoker of the bean instance's EJB object. When ejbActivate() is invoked in an entity bean there is no client (the bean is not associated with the client at this point), this means that the Container cannot return a Principal. Instead a java.lang.IllegalStateException will be thrown by the Container so the code will go into the catch block.

Answer 3 is incorrect due to the exception that will be thrown on the previous line. In any case "null" should never be returned from getCallerPrincipal() as the Container must never return a null from the getCallerPrincipal() method.

Answer 4 is incorrect, the method getCallerPrincipal() on the javax.ejb.EntityContext does return a reference to java.security.Principal if there is a valid client security context. This should not be confused with the method isCallerInRole() on the javax.ejb.EntityContext. isCallerInRole() method indicates if the entity bean instance's caller has a particular role (passed in as a parameter) by returning a boolean value.

5)2,4

Answer 1 is incorrect, the role of Secretary has permission to use the Remote method create.

Answers 2 and 4 are correct, the optional method-intf element can be used when it becomes necessary to differentiate between a method that is multiply defined across the enterprise bean's home and component interfaces the same name and signature.

The method-intf element allows a method element to differentiate between the methods with the same name and signature that are multiply defined across the home and component interfaces e.g. in both an enterprise bean's remote and local interfaces, or in both an enterprise bean's home and remote interfaces, etc. The method-intf element can be one of the following: Home, Remote, LocalHome or Local.

6)2,4

Answer 1 is incorrect, the Application Assembler is not responsible for changing code within the enterprise bean. This would be the responsibility of the Bean Provider. However this statement is still incorrect as the Bean Provider should not implement security mechanisms or hard-code security policies in the enterprise bean's business methods. They should instead rely on the security mechanisms provided by the EJB Container.

Answer 2 is correct, the Application Assembler can define one or more security roles in the deployment descriptor. The Application Assembler also assigns groups of methods of the enterprise bean's home and component interfaces to the security roles to define authorisation for the application. The Application Assembler does not need to know the security environment of the operational environment as the security roles are abstract, each role represents a type of user that should have the same access rights within the application.

Answer 3 is incorrect, as this is the responsibility of the Deployer. The Deployer assigns principals and/or groups of principals (such as individual users or user groups) used for managing security in the operational environment to the security roles defined in the security-role elements of the deployment descriptor.

Answer 4 is correct, the Application Assembler can specify the methods of the home and component interfaces that each security role is allowed to invoke using security roles that they have declared in the deployment descriptor. The Application Assembler can indicate that some methods should not be checked for authorization prior to invocation by the Container. The Application Assembler uses the unchecked element instead of a role name in the method-permission element to indicate that a method should not be checked for authorization. A security role or a method may appear in multiple method-permission elements.

7)2,3

The responsibilities as described in the EJB specification state that the Bean Provider and Application Assembler should describe all the requirements for the caller's principal management of inter-enterprise bean invocations as part of the description.

The Bean Provider should neither implement security mechanisms nor hard-code security policies in the enterprise bean's business methods.

The Bean Provider and Application Assembler may use the deployment descriptor to convey security-related information to the Deployer.

Deployer sets up the appropriate security policy for the enterprise bean application. Application Assembler and Deployer define the appropriate security policies for the application.

The management of caller principals passed on inter-enterprise bean invocations (i.e. principal delegation) is set up by the Deployer and System Administrator in a Container-specific way. For this reason 4 is incorrect as this is a responsibility of the Bean Provider.

8)2,3

Answer 1 is incorrect, EJB security supports authorisation of method permissions set at the interface level. This is achieved using the method-intf tag, which can be used to specify permissions on the Remote Home interface, Remote interface, LocalHome interface and the Local interface.

Answer 2 is correct, you can use the exclude-list element to indicate the set of methods are not allowed to be called. The Deployer should configure the enterprise bean's security such that no access is permitted to any method contained in the exclude-list. If a given method is specified both in the exclude-list element and in the method permission relation, the Deployer should configure the enterprise bean's security such that no access is permitted to the method. If any methods have not been assigned to any security roles and also do not appear in the exclude-list, the deployer should assign method permissions to them or specify them as unchecked.

Answer 3 is correct, you can use the run-as tag to indicate that specifying that a different principal be substituted for the execution of the methods of the bean's home and component interfaces and any methods of other enterprise beans that the bean may call. The Application Assembler specifies in the deployment descriptor whether the caller's security identity or a run-as security identity should be used for the execution of the bean's methods. If the run-as element is specified, a security principal that has been assigned to the specified security role will be used for the execution of the bean's methods and will be visible as the caller principal in the callee.

Answer 4 is incorrect, EJB security does not specify the exact security mechanisms that must be implemented and supported by the EJB Server. EJB security support is related to authorisation and not authentication details such as passwords.

9)Method permissions are defined in the deployment descriptor as a binary relation from the set of security roles to the set of methods of the home and component interfaces of session and entity bean's, including all their superinterfaces (including the methods of the EJBHome and EJBObject interfaces and/or EJBLocalHome and EJBLocalObject interfaces).

10)1,4

Answer 1 is correct, the Application Assembler may define method permissions. The Application Assembler defines method permissions using the method-permission tag elements. The Application Assembler defines the method permissions in the deployment descriptor using the method-permission elements. Each method-permission element includes a list of one or more security roles and a list of one or more methods. All the listed security roles are allowed to invoke all the listed methods. Each security role in the list is identified by the role-name element, and each method(or a set of methods, as described below) is identified by the method element. An optional description can be associated with a method-permission element using the description element. The method permissions relation is defined as the union of all the method permissions defined in the individual method-permission elements. A security role or a method may appear in multiple method-permission elements.

Answer 2 is incorrect, declarative security does not allow you to control authorisation at the bean instance level only at the class level. If you want to control authorisation at the bean instance level you have to use programmatic security.

Answer 3 is incorrect, EJB supports authorisation down to the bean's method level. With regards to authentication within EJB, the EJB specification does not specify the exact mechanisms that must be implemented and supported by the EJB Container. An EJB Container Provider has to provide the security mechanisms necessary to enforce the security policies set by the Deployer.

Answer 4 is correct, EJB supports both declarative and programmatic authorisation. In general, it is advised that security management should be enforced by the Container in a transparent manner to the enterprise bean's business methods. The Bean Provider should neither implement security mechanisms nor hard-code security policies in the enterprise bean's business methods. Rather, the Bean Provider should rely on the security mechanisms provided by the EJB Container, and should let the Application Assembler and Deployer define the appropriate security policies for the application. If information from the Security Context has to be retrieved you can use programmatic security. Using the method getCallerPrincipal() method to obtain a java.security.Principal interface representing the current caller other information can be available within an EJB business method.