Java EE / EJB Security

Transcription

1 Berner Fachhochschule Technik und Informatik Java EE / EJB Security Course Multi Tier Business Applications with Java EE Prof. Dr. Eric Dubuis Berner Fachhochschule Biel

2 Ambition Standard Security Modells Ambition general level that is, independent from the underlying accounting mechanism transparent for components declarative configuration extensible programmatic support 06/16/11 MTA with Java EE / Java EE Security 2

3 General Security Issues Authentication Making sure a user is who he claims he is Authorization (access control) Making sure a resource is accessed only by user who has access privileges Confidentially (security on the wire ) Protecting sensitive data while it is on the wire Data Integrity (security on the wire ) Making sure that data does not get modified while it is on the wire Non-Repudiation Proving that a user has performed a particular transaction Auditing Recording transactions 06/16/11 MTA with Java EE / Java EE Security 3

4 Java EE Security Issues App App Server Server Browser Browser Web Authentication Web Web container container Servlet Servlet Authorization EJB EJB container container EJB EJB EJB EJB Client Client Authentication Authentication/ Authorization Database Security on the Network wire 06/16/11 MTA with Java EE / Java EE Security 4

5 Security Services Container Security Services Container must restrict access to VM and host machine for authenticated users/applications only: vendor specific solutions Container must enforce security policy specified in the deployment descriptor: Web container EJB container Transport-Layer Security Services Provision of encryption over TCP/IP connections SSL & TSL Encryption between: browser and Web container EJB container and EJB container (CORBA) client and EJB container 06/16/11 MTA with Java EE / Java EE Security 5

6 Java EE Security Abstraction Differences exists between different operating environments ==> Java EE security is an abstraction Java EE security is represented in terms of roles and role mappings The latter relates the roles to: users and Group Group 1 groups User User 1 User User 2 User User 3 vendor-specific Role Role 1 Role Role 2 Role Role Ref Ref 1 Role Role Ref Ref 2 Java EE 06/16/11 MTA with Java EE / Java EE Security 6

7 Java EE Security Enforcement Authentication is performed by the Container Login mechanism when accessing Web components (standardized) Standalone/Application clients: Some mechanism such as: user authentication at startup-time (and using JAAS to connect to an existing security provider) access to the container-integrated authentication system Role-based Authorization is (mostly) done by the Container Declarative Authorization deployment descriptor specifies who can access what EJB and what method Programmatic Authorization program can query identity (also known as the principal) of a caller or check if caller has given role 06/16/11 MTA with Java EE / Java EE Security 7

8 Web Client Authentication Web client authentication is well standardized: Web Container asks for identity credentials Basic Authentication (Digest) Form-based Authentication Client Certificate Identity is stored in container (e.g. session) Then: Identity passed to EJB on method call or: Fixed identity: run-as deploy setting (Web container uses same identity for all users) 06/16/11 MTA with Java EE / Java EE Security 8

9 Standalone/Application Client Authentication Not (yet) standardized. You have to consider so far: Standalone versus Java EE application clients JNDI authentication JAAS authentication (JAAS: Java Authentication and Authorization Service) Client-side authentication Server-side authentication Server-side security proxies (JBoss: Can be used for establishing a security context) 06/16/11 MTA with Java EE / Java EE Security 9

10 Declarative Authorization at the EJB Tier Steps : 0. Security architect defines security policy: security roles (method) permissions 1. Deployer maps user identities, user groups to security roles 2. Deployer declares security roles in the deployment descriptor 3. Deployer declares method permissions 06/16/11 MTA with Java EE / Java EE Security 10

11 Step 1: Security Roles Security Roles: Senior Clerk staff member Junior Clerk staff member with limited responsibilities Director entitled to do anything Web Tier, Client Tier pseudo-user representing the Web tier/simple client (Tester a tester of the bank application) 06/16/11 MTA with Java EE / Java EE Security 11

12 Bank Application: Permissions The security architect defines the policy: AdminBean Senior C. Junior C. Director Web Tier Tester search customer X X X - X (note 2) get account X X (note 1) X - X (note 2) create customer X - X - X (note 2) delete customer - - X - X (note 2)... BankBean logon X X (note 2) logoff X X (note 2)... Assume further restrictions: Note 1) Clerks can get account information without balance. Note 2) The testers are authorized only during the testing phase. 06/16/11 MTA with Java EE / Java EE Security 12

13 Responsibilities of the Bean Provider/App Assembler You define Method Permissions as metadata annotations, or as elements in the deployment descriptor 06/16/11 MTA with Java EE / Java EE Security 13

14 Method Permissions (I) Method permissions can be expressed by using the following Level: class, Level: class, Level: method only Method permission can be expressed in the assembly part of the deployment descriptor, too. 06/16/11 MTA with Java EE / Java EE Security 14

15 Method Permission (II) Roles Allowed annotation specifies the security roles that are allowed to invoke the methods of the bean. Level: class, method Specifying annotation on the bean class means that it applies to all applicable interface methods of the class. Specifying the annotation on a method applies it to that method only. If the annotation is applied at both the class and the method level,the method value overrides if the two disagree. If annotation is applied to the bean class, is specified on an individual method, the value of annotation overrides for the given method. package RolesAllowed { String[] value(); } 06/16/11 MTA with Java EE / Java EE Security 15

16 Method Permission (IIa) Roles Allowed Example Using Annotations BankClerk ) public class BankAdminBean {... } method BankClerk, SeniorBankClerk }) public Customer lookupcustomerbyid(string id) {... } 06/16/11 MTA with Java EE / Java EE Security 16

17 Method Permission (IIb) Roles Allowed Example in the Deployment Descriptor <ejb-jar...>... <assembly-descriptor> <security-role><role-name>bankclerk</role-name> </security-role> <security-role><role-name>seniorbankclerk</role-name> </security-role> <method-permission> <role-name>bankclerk</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>*</method-name> </method> </method-permission>... 06/16/11 MTA with Java EE / Java EE Security 17

18 Method Permission (IIc) Roles Allowed Example in the Deployment Descriptor <ejb-jar...>... <assembly-descriptor>... <security-role><role-name>seniorbankclerk</role-name> </security-role> <method-permission> <role-name>seniorbankclerk</role-name> <method> <ejb-name>bankbean</ejb-name> <method-name>lookupcustomerbyid</method-name> </method> </method-permission>... union union with with BankClerk BankClerk 06/16/11 MTA with Java EE / Java EE Security 18

19 Method Permission (III) Permit All annotation specifies that all security roles are allowed to invoke the specified method(s). package ({TYPE, PermitAll {} In the DD: <method-permission> <unchecked/> <method> <ejb-name>xxxx</ejb-name> <method-name>yyyy</method-name> </method> </method-permission> but but caller caller must must be be authenticated 06/16/11 MTA with Java EE / Java EE Security 19

20 Method Permission (IV) DenyAll annotation specifies that no security roles are allowed to invoke the specified method. package DenyAll {} Exclude List <assembly-descriptor> <exclude-list> <method> <ejb-name>...</> <method-name>...</> </method>... </exclude-list> 06/16/11 MTA with Java EE / Java EE Security 20

21 Method Permission (V) Note If is specified on the method or class level, and nothing is said in the deployment descriptor then the permission of the methods of theses classes default to: <unchecked/> <method> <ejb-name>xxxx</ejb-name> <method-name>*</method-name> </method 06/16/11 MTA with Java EE / Java EE Security 21

22 Run As Security Identity (I) RunAs annotation is used to specify the bean s run-as property. That is, it specifies the role under which every interface method of the bean RunAs { String value(); } In the DD: <enterprise-beans> <session> <ejb-name>... <security-identity> <run-as><role-name>role</role-name></run-as> </security-identity> </session> 06/16/11 MTA with Java EE / Java EE Security 22

23 Run As Security Identity (II) To specify that a bean will execute under the caller's identity rather than the propagated run-as identity, the <securityidentity> contains a single <use-caller-identity/> element: <enterprise-beans> <session> <ejb-name>...</ejb-name> <security-identity> <use-caller-identity</> </security-identity> </session> </enterprise-beans> 06/16/11 MTA with Java EE / Java EE Security 23

24 Programmatic Security (I) Programmatic Access to Caller's Security Context EJBContext.getCallerPrincipal(): Returns the principal name of the caller. Can be used as a key for database access. Not reliable, however, since security realms may provide different principal names for the same user. EJBContext.isCallerInRole(String): Returns true iff the caller is in the (logical) role as specified with argument String. 06/16/11 MTA with Java EE / Java EE Security 24

25 Programmatic Security (II) Using getcallerprincipal(): Can be used to get the principal name of the caller, for example for logging purposes. Note: The format of the principal name depends on the format of the domain of the user names of the authenticated users. For Kerberos, for example, it might look like 06/16/11 MTA with Java EE / Java EE Security 25

26 Programmatic Security (III) Using iscallerinrole(string) EJBContext.isCallerInRole(String): Returns true iff the caller is in the (logical) role as specified with argument String. Relevant annotation: DeclareRoles { String[] value(); } 06/16/11 MTA with Java EE / Java EE Security 26

27 Programmatic Security (IIIa) Usage of caller BankClerk ) public class BankBean implements Payroll private SessionContext context; } public double lookupbalance(...) {... if (context.iscallerinrole( BankClerk ) {... } } 06/16/11 MTA with Java EE / Java EE Security 27

28 Responsibilities of the Deployer For Glassfish V3.x, provide a role mapping file named glassfish-ejb-jar.xml. It looks like: <!DOCTYPE glassfish-ejb-jar PUBLIC "-//GlassFish.org// DTD GlassFish Application Server 3.1 EJB 3.1//EN" " <glassfish-ejb-jar> <security-role-mapping> <role-name>sales</role-name> <principal-name>s1</principal-name> </security-role-mapping> <security-role-mapping> <role-name>customer</role-name> <group-name>customers</group-name> </security-role-mapping>... </glassfish-ejb-jar> See also: 06/16/11 MTA with Java EE / Java EE Security 28

29 Responsibilities of the Application Client Programmer You don't add any security code when using the application client container to start your client. The application client container uses so-called callback handlers for optaining the user credentials (user name, password, for example). By default, a GUI-based callback handler is used. A command line callback handler is used when you specify: appclient -client <client-jar> -textauth The callback handler is called the first time you access (typically, calling a business method) it. Having entered the login credentials a role is attributed to the client's session. By default, this role cannot be altered anymore. To alter the role (some client applications might require this), you must use the JAAS API, in particular, the LoginModule. This module allows to make a login() at the beginning of the execution of a client program. It also allows to make a logout(), for example, to change the role. 06/16/11 MTA with Java EE / Java EE Security 29