Realms, Users, Groups: Web Security Example

1. CS441 CURRENT TOPICS IN PROGRAMMING LANGUAGES Lecture 20 George Koutsogiannakis Summer 2011

2. Topics • Realms, Users, Groups. • Web Security Example. • Application Server Security. • Web Services definitions.

3. Realms, Users, Groups • A Realm is defined on the Application Server or the Web Server. • In this lecture we assume that GlassFish is used regardless if the application is just a web application or a combination of web/ejb.

4. Realms, Users, Groups • A REALM • Contains a collection of users that are covered by the same authentication policy. • Users are assigned to roles as discussed in previous lecture. • A Group is a set of authenticated users classified by common traits defined in the Application Server.

5. Realms, Users, Groups • Realm appears as a data source (can be a table) of users and groups. • There are 3 mappings of Realm: • file:all clients except those that use certificates and HTTPS. • certificate: clients are authenticated using certificates and HTTPS • admin-realm: special realm reserved for administrators to manage users.

6. Realms, Users, Groups • Realm contains a collection of users which may or may not be assigned to a group. • For a web application, a realm is a complete database of users and groups that identify valid users of a web application (or a set of web applications) and are controlled by the same authentication policy.

7. Realms, Users, Groups • A user is an individual (or application program) identity that has been defined in the Application Server. • In a web application, a user can have a set of roles associated with that identity, which entitles them to access all resources protected by those roles. Users can be associated with a group.

8. Realms, Users, Groups • A group is a set of authenticated users, classified by common traits, defined in the Application Server. • Principal: A principal is an entity that can be authenticated by an authentication protocol in a security service that is deployed in an enterprise (in other words a user). • Security policy domain (also known as security domain or realm): A security policy domain is a scope over which a common security policy is defined and enforced by the security administrator of the security service.

10. Web Security Example • Overview of Web Application Security • In the Java EE platform, web components provide the dynamic extension capabilities for a web server. Web components are either Java servlets, JSP pages, JSF pages, or web service endpoints.

12. Web Security Example • Basic Authentication with a Servlet • Add an authorized user to the Application Server. • Start the Application Server in NetBeans services window. • Start the Admin Console by right clicking on the server in NetBeans and choosing view admin console.. • To log in to the Admin Console, enter the user name and password of a user in the admin-realm who belongs to the asadmin group. The name and password entered during installation will work, as will any users added to this realm and group subsequent to installation. • Expand the Configuration node in the Admin Console tree.

13. Web Security Example-Add user to Application Server • Expand the Security node in the Admin Console tree. • Expand the Realms node. • Select the file realm to add users you want to enable to access applications running in this realm. (For the example security applications, select the file realm.) • Select the admin-realm to add users you want to enable as system administrators of the Application Server. • You cannot enter users into the certificate realm using the Admin Console. You can only add certificates to the certificate realm.

14. Web Security Example-Add user to Application Server • Click the Manage Users button. • Click New to add a new user to the realm. • Enter the correct information into the User ID, Password, and Group(s) fields. • If you are adding a user to the file realm, enter the name to identify the user, a password to allow the user access to the realm, and a group to which this user belongs.

15. Web Security Example-Add user to Application Server • For the example security applications, enter a user with any name and password you like, but make sure that the user is assigned to the group of user. • If you are adding a user to the admin-realm, enter the name to identify the user, a password to allow the user access to the Application Server, and enter asadmin in the Group field. • Click OK to add this user to the list of users in the realm. • Click Logout when you have completed this task.

16. Web Security Example-Add roles • Add roles: • You can add roles in the web.xml descriptor file. The following is an example of a security constraint from a web.xml application deployment descriptor file where • the role of DEPT-ADMIN is authorized for methods that review employee data and • the role of DIRECTOR is authorized for methods that change employee data. <security-constraint> <web-resource-collection> <web-resource-name>view dept data</web-resource-name> <url-pattern>/hr/employee/*</url-pattern> ` <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection>

17. Web Security Example-Add roles <auth-constraint> <role-name>DEPT_ADMIN</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>

18. Web Security Example-Add roles <security-constraint> <web-resource-collection> <web-resource-name>change dept data</web-resource-name> <url-pattern>/hr/employee/*</url-pattern> <http-method>GET</http-method> <http-method>PUT</http-method> </web-resource-collection> <auth-constraint> <role-name>DIRECTOR</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>

19. Web Security Example-Add roles • Notice the element <user-data-constraint> This element requires that all security contraint URL pattrens and HTTP methods are received over a protected transport layer. • The choice COFIDENTIAL means that the transmitted data can not be accessed by other entities. HTTPS is used (SSL) • Notice the element <auth-constraint> is used to define the users in their roles. • The element <web-resource-collection> idetifies the URLs (resources) to be protected. • Another element (not shown) is <login-config> is used to authenticate access to the web content by a user (before any request is processed base don a role).

20. Web Security Example-Add roles • The last step is to map the security role to the name of a user, or principal (in the application server). • The security architecture provides a mechanism for mapping the roles defined in the application to the users or groups defined in the runtime realm. • Use the security-role-mapping element in the runtime deployment descriptor (sun-application.xml, sun-web.xml, or sun-ejb-jar.xml) file.

21. Web Security Example-Add roles • The entry needs to declare a mapping between a security role used in the application and one or more groups or principals defined for the applicable realm of the Application Server. An example for the sun-web.xml file is shown below: • <sun-web-app> <security-role-mapping> <role-name>DIRECTOR</role-name> <principal-name>mcneely</principal-name> </security-role-mapping> <security-role-mapping> <role-name>DEPT_ADMIN</role-name> <group-name>administrators</group-name> </security-role-mapping> </sun-web-app>

22. Web Security Example-Servlets • Create a web module hello2. The subsequent steps discuss adding security to this basic application. The files for this example application are in tut-install/javaeetutorial5/examples/web/hello2_basicauth/. • There are two servlets: • GreetingSerlet.java • ResponseServlet.java

23. Web Security Example-Servlets @DeclareRoles("helloUser") public class GreetingServlet extends HttpServlet { public void doGet( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); response.setBufferSize(8192); PrintWriter out = response.getWriter(); // then write the data of the response out.println("<html>" + "<head><title>Hello</title></head>"); out.println("<body bgcolor=\"#ffffff\">"

24. Web Security Example-Servlets + "<img src=\"duke.waving.gif\" alt=\"Duke waving\">" + "<h2>Hello, my name is Duke. What's yours?</h2>" + "<form method=\"get\">" + "<input type=\"text\" name=\"username\" size=\"25\">" + "<p></p>" + "<input type=\"submit\" value=\"Submit\">" + "<input type=\"reset\" value=\"Reset\">" + "</form>"); String username = request.getParameter("username"); if ((username != null) && (username.length() > 0)) { RequestDispatcher dispatcher = getServletContext().getRequestDispatcher( "/response"); if (dispatcher != null) { dispatcher.include(request, response);} } out.println("</body></html>"); out.close(); }

25. Web Security Example-Servlets public String getServletInfo() { return "The Hello servlet says hello."; } }

26. Web Security Example-Servlets public class ResponseServlet extends HttpServlet { public void doGet( HttpServletRequest request,HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getWriter(); // then write the data of the response String username = request.getParameter("username"); if ((username != null) && (username.length() > 0)) { out.println("<h2>Hello, " + username + "!</h2>"); } } public String getServletInfo() { return "The Response servlet says hello."; } }

27. Web Security Example-Servlets • Declare the roles that will be used in this application. For this example, this is done by adding the @DeclareRoles annotation to GreetingServlet.java. • The deployment descriptor web.xml should have the role described :

28. Web Security Example-web.xml • <security-constraint> <display-name>SecurityConstraint</display-name> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/greeting</url-pattern> </web-resource-collection> <auth-constraint> <role-name>helloUser</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>file</realm-name> </login-config>

29. Web Security Example-sun-web.xml (Application Server) • Map the role name defined for this resource (helloUser) to a group of users defined on the Application Server. • That is the roles define din the web.xml must be linked to the users in the Application Server. • Mapping Application Roles to Application Server Groups • Map the role of helloUserdefined in the application to the group of user defined on the Application Server by adding a security-role-mapping element to the sun-web.xml runtime deployment descriptor file.

30. Web Security Example-sun-web.xml • The runtime deployment descriptor is an XML file that contains information such as the context root of the web application and the mapping of the portable names of an application’s resources to the Application Server’s resources.

31. Web Security Example-sun-web.xml <sun-web-app> <context-root>/hello2_basicauth</context-root> <security-role-mapping> <role-name>helloUser</role-name> <group-name>user</group-name> </security-role-mapping> </sun-web-app>

32. Web Security Example • Add authorized users to the file type realm of the Application Server • Build, package, and deploy the web application.

33. Summary of Security Settings for a Web Application • Identify realms . Groups and users in the Application server. • Create the web.xml security role sin combination with annotations in your web resources code. • Identify the security roles.

34. Summary of Security Settings for a Web Application • Map the security roles to the security constraints in the Application server. • Elements of the security constraints will define the users/group that pertain to the particular role and the security restrictions for that role. • Notice that the security restrictions are linked to particular resources defined in the proper element.

35. Security for Java EE Components. • Let us discuss security for Enterprise Beans. • Enterprise Beans can be called from application clients or from web applications (as in previous slides). • The EJB container can provide additional security pertaining to the beans. This can be accomplished in a declarative way and/or in a programmatic way.

37. Security for Java EE Components • You can protect enterprise beans by doing the following: • Accessing an Enterprise Bean Caller's Security Context • Declaring Security Role Names Referenced from Enterprise Bean Code • Defining a Security View of Enterprise Beans • Using Enterprise Bean Security Annotations • Using Enterprise Bean Security Deployment DescriptorElements.

38. Security for Java EE Components • Accessing an Enterprise Bean Caller’s Security Context • In general, security management should be enforced by the container in a manner that is transparent to the enterprise beans’ business methods. • The security API described in this section should be used only in the less frequent situations in which the enterprise bean business methods need to access the security context information.

39. Security for Java EE Components • The javax.ejb.EJBContext interface provides two methods that allow the bean provider to access security information about the enterprise bean’s caller. • java.security.Principal getCallerPrincipal(); The purpose of the getCallerPrincipal method is to allow the enterprise bean methods to obtain the current caller principal’s name. The methods might, for example, use the name as a key to information in a database. • boolean isCallerInRole(String roleName); The purpose of the isCallerInRole(String roleName) method is to test whether the current caller has been assigned to a given security role.

40. Security for Java EE Components • If we assume, for example, that the current caller user contains the primary key used for the identification of employees (for example, employee number): / /obtain the caller principal callerPrincipal = ctx.getCallerPrincipal(); // obtain the caller principal’s name. callerKey = callerPrincipal.getName(); // use callerKey as primary key to find EmployeeRecord EmployeeRecord myEmployeeRecord = em.findByPrimaryKey(EmployeeRecord.class, callerKey);

41. Security for Java EE Components • Declaring Security Role Names Referenced from Enterprise Bean Code • You can declare security role names used in enterprise bean code using either the @DeclareRoles annotation (preferred) or the security-role-ref elements of the deployment descriptor.

42. Security for Java EE Components • Defining a Security View of Enterprise Beans • You can define a security view of the enterprise beans contained in the ejb-jar file and pass this information along to the deployer. • When a security view is passed on to the deployer, the deployer uses this information to define method permissions for security roles. • If you don’t define a security view, the deployer will have to determine what each business method does to determine which users are authorized to call each method.

43. Security for Java EE Components • A security view consists : • of a set of security roles, a semantic grouping of permissions that a given type of users of an application must have to successfully access the application. Security roles are meant to be logical roles, representing a type of user. • You can define method permissions for each security role. • A method permission is a permission to invoke a specified group of methods of the enterprise beans’ business interface, home interface, component interface, and/or web service endpoints. • You can specify an authentication mechanism that will be used to verify the identity of a user.

44. Security for Java EE Components • Use the @DeclareRoles and @RolesAllowed annotations to define security roles using Java language annotations. • The set of security roles used by the application is the total of the security roles defined by the security role names used in the @DeclareRoles and @RolesAllowed annotations (multiple roles can be defined).

45. Security for Java EE Components • Enterprise JavaBeans components use an EJB deployment descriptor that must be named : • META-INF/ejb-jar.xml (must be contained in the EJB JAR file). • The role of the deployment descriptor is to relay information to the deployer about security and other aspects of the application. Specifying this information in annotations or in the deployment descriptor helps the deployer set up the appropriate security policy for the enterprise bean application.

46. Security for Java EE Components • The following is a listing of deployment descriptor elements that address security: • The security-role-ref element declares each security role referenced in the code. • The security-role element defines broad categories of users, and is used to provide access to protected methods. • The method-permission element is used to specify method permissions. • The run-as element is used to configure a component’s propagated security identity.

47. Security for Java EE Components • You can augment the set of security roles defined for the application by annotations using the security-role deployment descriptor in the ejb-jar.xml file. i.e. <security-role> <description> This role includes the employees of the enterprise who are allowed to access the employee self-service application. This role is allowed only to access his/her own information. </description> <role-name>employee</role-name> </security-role>

48. Security for Java EE Components • We have two levels of security: • We are trying to set the security references of the component. • We also have the security references at the application level. • The two need to be linked. • In the absence of explicit linking a role at the component level will be linked automatically to a role with the same name at the application level. • Or, you can explicitly link all the security role references declared in the @DeclareRoles annotation or security-role-ref elements for a component to the security roles defined by the use of annotations and/or in the security-role elements.

49. Security for Java EE Components • You can use the role-link element to link each security role reference of a component to a security role at the application level i.e. <session> <ejb-name>AardvarkPayroll</ejb-name> <ejb-class>com.aardvark.payroll.PayrollBean</ejb-class> ... <security-role-ref> <description> This role should be assigned to the employees of the payroll department. Members of this role have access to anyone’s payroll record. The role has been linked to the payroll-department role. </description> <role-name>payroll</role-name> <role-link>payroll-department</role-link> </security-role-ref> ... </session>

50. Security for Java EE Components • Specifying Method Permissions • If you have defined security roles for the enterprise beans in the ejb-jar file, you can also specify the methods of the business interface, home interface, component interface, and/or web service endpoints that each security role is allowed to invoke.