330 likes | 353 Views
Implementing Security in J2EE Applications. Objectives. After completing this lesson, you should be able to do the following: Define Java Authentication and Authorization Service (JAAS) Define security issues regarding Web applications and Enterprise JavaBeans (EJB)
E N D
Objectives • After completing this lesson, you should be able to do the following: • Define Java Authentication and Authorization Service (JAAS) • Define security issues regarding Web applications and Enterprise JavaBeans (EJB) • List the security attributes of the Java Naming and Directory Interface (JNDI) Context interface
Goals of J2EE Security Architecture • Lessen the burden of the application developer in securing applications • Ensure fine-grained access control to the EJB resources • Enable portable and secured Web applications and EJBs
Overview of J2EE Security Architecture • Use Java Authentication and Authorization Service (JAAS) APIs to: • Authenticate a client to access the system • Define security identities (principal/users), groups, and roles to identify clients to the container • Associate principals to the client to enable access to the bean methods • Authorize clients to access the bean methods • Define logical roles, set method permissions, and map roles to users in the deployment descriptors • Use containers to authorize the client requests to the methods
Java Authentication and Authorization Service (JAAS) • JAAS is a framework that: • Provides a Java API package to enable applications to authenticate and enforce security • Allows definition of logical security names that are mapped in deployment descriptors to users or roles defined in the run-time environment • Controls access to Web applications based on URL patterns • Allows fine-grained authorization to manage how clients can access bean methods • A JAAS provider implements the JAAS framework and applies the Java2 Security Model.
Java Authentication and Authorization Service (JAAS) • JAAS supports the following authorization, authentication, and user community (realm) features: • Principals • Subjects • Login module authentication • Roles • Realms • Policies • Permissions
Authorization of a Client • The authorization is specified in the J2EE-specific and OC4J-specific deployment descriptors. • Security roles • Define the security view of the application to the deployer • Must be mapped to the appropriate security principals in the target environment • Every client obtains a security principal. • A client can invoke a URL or a method only if the client’s role has the associated invocation rights. • The container provider enforces the security policies and provides the tools for managing security.
JAAS Provider Types in OC4J • The JAAS provider in Oracle Application Server 10g Containers for J2EE (OC4J) supports two provider types: • The LDAP-based provider type that is used to access an Oracle Internet Directory (OID) repository • The XML-based provider type that is used to access an XML file repository by using: • The jazn-data.xml file • The principals.xml file • The repositories store the realm (users and roles) and the policy (permissions) information.
Configuring Security • Define users and groups in jazn-data.xml (or principals.xml). • Define security view or logical roles in J2EE deployment descriptor (web.xml or ejb-jar.xml). • Map logical roles to users and groups in OC4J-specific deployment descriptor (orion-web.xml or orion-ejb-jar.xml). • Provide a user or group with read and write access to the Java Naming and Directory Interface (JNDI) namespace in application.xml (or application-specific orion-application.xml).
Defining the Users, Groups, and Roles • The identities (users and groups) are known to the container by using the jazn-data.xml. • The identities can be specific to an application. <jazn-realm> <realm><name>jazn.com</name> <users> <user><name>admin</name> <display-name>OC4J Administrator</display-name> <description>OC4J Administrator</description> <credentials>{903}5NwtZOAJa2Ty7Ksbmu3IUOfK9PgK/Kxi </credentials> </user> <user><name>user</name> <description>The default user</description> <credentials>{903}/pQcVBQ6+AN+NNF2MzYb/0+gR4lOVwwh </credentials> </user> ...
Managing Users and Groupswith the JAZN Admintool • The JAZN Admintool can manage users, roles, and groups and can assign roles to users in XML or LDAP-based data. • It modifies jazn-data.xmlor the LDAP repository. • It prompts for admin username and password. • Examples: • Adding a user: • Adding a role (or a group): • Granting a role to a user (assign user to a group): java –jar jazn.jar –adduser jazn.com ora1 oracle java –jar jazn.jar –addrole jazn.com managers java –jar jazn.jar –grantrole manager jazn.com ora1
Defining the Logical Roles • The logical security roles defined in the J2EE deployment descriptors are: • Specified in the web.xml file for Web applications, or in the ejb-jar.xml file for EJB components. • Defined in the <security-role> element for the application. One or more roles can be specified. • Authorized to invoke methods that are listed in the <method-permissions> element for the security role. • Scoped at the level of the application orall the enterprise beans in the jar file.
Defining and Using Logical Roles in Web Applications (web.xml) • Define logical role in the <security-role> element • Use role in <security-constraint> element <security-role> <role-name>hr_managers</role-name> <!--define--></security-role><security-constraint> <web-resource-collection> <web-resource-name>UpdEmployee</web-resource-name> <url-pattern>/UpdEmployees.jsp</url-pattern> </web-resource-collection> <auth-constraint> <role-name>hr_managers</role-name> <!--apply--> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint></security-constraint>
Defining and Using Logical Roles in EJBs (ejb-jar.xml) • Define logical role in <security-role> element. • Assign access in <method-permission> element. <assembly-descriptor> <security-role> <description>HR Manager</description> <role-name>hr_managers</role-name> </security-role> <method-permission> <role-name>hr_managers</role-name> <method><ejb-name>HrApp</ejb-name> <method-name>incrementSalary</method-name> <method-params><method-param>int</method-param> <method-param>int</method-param></method-params> </method></method-permission> ... <assembly-descriptor> ...
Mapping Logical Roles to Users and Groups • Mapping is done in the OC4J deployment descriptors. • A logical role to a group: • A logical role to a user: • A logical role to a group or a specific user: <security-role-mapping name = "hr_managers"> <group name="managers"/> </security-role-mapping> <security-role-mapping name = "hr_managers"> <user name="ora1"/> </security-role-mapping> <security-role-mapping name = "hr_managers"> <group name="managers"/> <user name="ora1"/> </security-role-mapping>
Programmatic Access to a Caller’s Security Context • Not all security policies can be expressed declaratively. • Use a programmatic interface to access the security context of the calling client from the bean methods. • To access the security information of the caller, the javax.ejb.EJBContext interface defines the following two methods: java.security.Principal getCallerPrincipal(); boolean isCallerInRole(java.lang.String roleName);
Client Authentication • For Web applications: • Use Web application server security mechanisms, where credentials are passed through to the J2EE environment • Use OC4J container Web security Examples: Basic or Digest Authentication, HTML form fields, and Client SSL certificates • For EJB components: • Stand-alone (remote) clients define credentials in InitialContext, and the jndi.properties file or settings in a Hashtable. • Local clients, such as servlets, JSPs, or other EJBs, pass their credentials by using the Context object.
EJB Client Authentication with the jndi.properties file • In the jndi.properties file: • Client accessing the EJB with the above JNDI properties: java.naming.security.principal=ora1 java.naming.security.credentials=welcome java.naming.factory.initial=com.evermind.server.\ApplicationClientInitialContextFactory java.naming.provider.url=ormi://localhost/hrApp Context ic = new InitialContext(); EmployeeHome = (EmployeeHome) ic.lookup( "java:comp/env/Employee");
EJB Client Authentication with a Hashtable Hashtable env = new Hashtable(); env.put("java.naming.provider.url", "ormi://localhost/hrApp"); env.put("java.naming.factory.initial", "com.evermind.server." + "ApplicationClientInitialContextFactory"); env.put(Context.SECURITY_PRINCIPAL, "ora1"); env.put(Context.SECURITY_CREDENTIALS, "welcome"); Context ic = new InitialContext (env); EmployeeHome = (EmployeeHome) ic.lookup( "java:comp/env/Employee");
Setting Access Control with JDeveloper • You can set security roles to access a Web application or an EJB by using JDeveloper deployment descriptor editors: • Use the Web Application Deployment Descriptor editor for Web applications. • Use the EJB Module Editor for EJBs. • For Web applications, set the access permissions as constraints defining URL patterns for a Web resource. • For EJBs, set the access permissions for either individual methods or all the methods of the bean.
Creating Web Application Security Roles 1. Right-click web.xml, select Properties. 2. In the Security Roles section, click Add.
Web Application Login Authentication • Typically done using Oracle HTTP Server using either Basic, Digest, Login Form, Single-Sign On, and so on.
Web Application Authorization • Define a Web resource (URLs and HTTP methods). • Grant security roles access to the Web resource.
Creating EJB Security Roles 1. Select the Security Roles section. 2. Click Add to create and enter a new logical role name and description in the Create Security Role dialog window.
Setting Method Permissions • In the Method Permissions section, select the roles and the methods that are accessible for those roles.
Method Access in EJB Deployment Descriptors • The example shows the hr_managers role granted access to the incrementSalary() method. • Explicit settings have precedence over default method access in the OC4J deployment descriptor.
Creating a Mapping for the Logical Roles • In JDeveloper, edit the orion-ejb-jar.xml file. 1. Right-click the file and select Properties. 2. Select Security Role Mapping, and then click Add. 3. Enter a logical role name (e.g., hr_managers).
Mapping Results in orion-ejb-jar.xml • The OC4J XML Deployment Descriptor holds the details for mapping the logical role to the allowed identities (groups or users). • For example:
Accessing the EJB with New Permissions • Any client with a role other than those specified in the deployment descriptor receives the exception com.evermind.server.rmi.OrionRemoteException. • Clients without read/write access to the namespace receive the exception javax.naming.NoPermission.
Summary • In this lesson, you should have learned how to: • Use the J2EE security architecture to remove from the developer the burden of implementing security • Define Web applications and EJB security mechanisms such as security roles • Define users, groups, and logical roles; map the logical and concrete roles for client authorization • Access security information of the caller by using methods in the javax.ejb.EJBContext interface • Authenticate EJB client applications by using the jndi.properties file and InitialContext
Practice 20-1: Overview • This practice covers the following topics: • Using the Web Application Deployment Descriptor to create logical security roles for a Web application • Enabling basic authentication in an OC4J container • Programmatically determining the user credentials and using it to control access to information • Using EJB security to control access to methods in a bean