Скачать презентацию Faculty of Information Technology Advanced Java Programming Security Скачать презентацию Faculty of Information Technology Advanced Java Programming Security

ef443b21dca9122a70ad6ca21edacdbe.ppt

  • Количество слайдов: 59

Faculty of Information Technology Advanced Java Programming Security Chris Wong chw@it. uts. edu. au Faculty of Information Technology Advanced Java Programming Security Chris Wong [email protected] uts. edu. au Based on notes by Wayne Brookes © Copyright UTS Faculty of Information Technology – Security 1

Topics Faculty of Information Technology • Security background – – Confidentiality, Integrity, Availability Authentication, Topics Faculty of Information Technology • Security background – – Confidentiality, Integrity, Availability Authentication, Authorisation, Non-repudiation Cryptography primer Digital certificates • Basic Java security – JCA, JCE, JSSE, JAAS • Enterprise Java security – Declarative vs Programmatic © Copyright UTS Faculty of Information Technology – Security 2

Introduction Faculty of Information Technology • Security is about protecting your application from attacks Introduction Faculty of Information Technology • Security is about protecting your application from attacks – from those external to the application – from application users who try to exceed their authority • Basic Principles – Confidentiality – Integrity – Availability © Copyright UTS Faculty of Information Technology – Security 3

Confidentiality Faculty of Information Technology • Ensuring that data is only seen by valid Confidentiality Faculty of Information Technology • Ensuring that data is only seen by valid users – again, protection of "in-transit" data important • Relies upon correct authentication/authorisation – valid users can't see data they're not permitted to • Encryption of data commonly used • Classes of encryption algorithm: – symmetric (DES, 3 DES, RC 5, etc) – asymmetric (RSA, Diffie-Hellman) © Copyright UTS Faculty of Information Technology – Security 4

Confidentiality Faculty of Information Technology • Ensuring that data is only seen by valid Confidentiality Faculty of Information Technology • Ensuring that data is only seen by valid users • Keep it “Not seen” by: Securing Location & Transmission of data. Using ENCRYPTION. • Who are valid users? Use AUTHENTICATION. Use AUTHORISATION. © Copyright UTS Faculty of Information Technology – Security 5

Confidentiality 2 Faculty of Information Technology Typical methods: • Physical/Logical security – Eg: firewalls, Confidentiality 2 Faculty of Information Technology Typical methods: • Physical/Logical security – Eg: firewalls, DMZ, VPN, tunnelling • Encryption of data – symmetric (DES, 3 DES, RC 5, AES, etc) – asymmetric (AES, RSA, Diffie-Hellman, IDEA) • Authentication ie: identify userid • Authorisation ie: Access Control © Copyright UTS Faculty of Information Technology – Security 6

Integrity Faculty of Information Technology • Ensuring that data is not tampered with – Integrity Faculty of Information Technology • Ensuring that data is not tampered with – In transit? Protect data over network. What about the Internet? – In storage? Protect Database/File System/Operation System – Also needs correct authentication & authorisation! • Typical methods: – Message Digest (“fingerprint”) • Eg: Message Digest 5 (MD 5) – Hash functions • SHA (Secure Hash Algorithm) – CRC Provide a complex "checksum" of the original data © Copyright UTS Faculty of Information Technology – Security 7

Availability Faculty of Information Technology • Ensure valid user can access data/system WHEN required Availability Faculty of Information Technology • Ensure valid user can access data/system WHEN required • Typical techniques: – Fail-safe systems eg: Hot Standby – Backup/redundancy eg: Clustering – Resilience to attacks eg: Denial of Service attacks, Viruses, Worms etc – Access controls – from valid locations only eg: intranet/extranet © Copyright UTS Faculty of Information Technology – Security 8

Topics Faculty of Information Technology • Security background – Confidentiality, Integrity, Availability Authentication, Authorisation. Topics Faculty of Information Technology • Security background – Confidentiality, Integrity, Availability Authentication, Authorisation. Non-repudiation , – Cryptography primer – Digital certificates • Basic Java security – JCA, JCE, JSSE, JAAS • Enterprise Java security – Declarative vs Programmatic © Copyright UTS Faculty of Information Technology – Security 9

Authentication/ Identification Faculty of Information Technology • Establishing who the user is • Classes Authentication/ Identification Faculty of Information Technology • Establishing who the user is • Classes of techniques: – – Password ("something you know") Token ("something you possess") Biometric ("something you are") Certificate ("trusted 3 rd party knows you") © Copyright UTS Faculty of Information Technology – Security 10

Authorisation/ Access Control Faculty of Information Technology • Establishing what the user is permitted Authorisation/ Access Control Faculty of Information Technology • Establishing what the user is permitted to do • Relies upon correct authentication of user – Access Control List (ACL) is a common technique • ACLs are common: – for a resource, provide a list of users who can access it, and what level of access each user has • Access control may be: – discretionary (ACLs based on users or groups) – role-based (ACLs based on user "roles“) © Copyright UTS Faculty of Information Technology – Security 11

Non-repudiation Faculty of Information Technology • Ensuring that a user cannot deny having carried Non-repudiation Faculty of Information Technology • Ensuring that a user cannot deny having carried out some action • Relies upon all other security services • May be based on digital signatures – if you have a message digitally signed by a user, the user cannot deny having sent it. . . –. . . assuming the user was correctly authenticated, access control was correctly applied, the message was not tampered with, and no other user could have generated the digital signature • Also relates to auditing © Copyright UTS Faculty of Information Technology – Security 12

Topics Faculty of Information Technology • Security background – Confidentiality, Integrity, Availability – Authentication, Topics Faculty of Information Technology • Security background – Confidentiality, Integrity, Availability – Authentication, Authorisation, Non-repudiation Cryptography primer – Digital certificates • Basic Java security – JCA, JCE, JSSE, JAAS • Enterprise Java security – Declarative vs Programmatic © Copyright UTS Faculty of Information Technology – Security 13

Cryptography primer Faculty of Information Technology • Encryption takes as input some plaintext data Cryptography primer Faculty of Information Technology • Encryption takes as input some plaintext data and an encryption key, and generates ciphertext • Decryption takes ciphertext and a decryption key, and generates plaintext • Two main kinds of cryptography: – Symmetric (aka "private key" or "secret key" crypto): Same key for encryption and decryption – faster – Asymmetric (aka "public key" crypto): Different keys for encryption and decryption – slower © Copyright UTS Faculty of Information Technology – Security 14

Symmetric Key Crypto Faculty of Information Technology • Used for confidentiality cleartext Crypto engine Symmetric Key Crypto Faculty of Information Technology • Used for confidentiality cleartext Crypto engine ENCODE ciphertext secret key © Copyright UTS Faculty of Information Technology – Security Crypto engine DECODE cleartext secret key 15

Asymmetric Key Crypto 1 Faculty of Information Technology • Used for confidentiality cleartext Crypto Asymmetric Key Crypto 1 Faculty of Information Technology • Used for confidentiality cleartext Crypto engine ENCODE ciphertext Public Key © Copyright UTS Faculty of Information Technology – Security Crypto engine DECODE cleartext Private Key 16

Asymmetric Key Crypto 2 Faculty of Information Technology • Used for identity and non-repudiation Asymmetric Key Crypto 2 Faculty of Information Technology • Used for identity and non-repudiation • aka "digital signature" cleartext Crypto engine ENCODE ciphertext Private Key © Copyright UTS Faculty of Information Technology – Security Crypto engine DECODE cleartext Public Key 17

Topics Faculty of Information Technology • Security background – Confidentiality, Integrity, Availability – Authentication, Topics Faculty of Information Technology • Security background – Confidentiality, Integrity, Availability – Authentication, Authorisation, Non-repudiation – Cryptography primer Digital certificates • Basic Java security – JCA, JCE, JSSE, JAAS • Enterprise Java security – Declarative vs Programmatic © Copyright UTS Faculty of Information Technology – Security 18

Digital Certificates Faculty of Information Technology • A certificate can be used to identify Digital Certificates Faculty of Information Technology • A certificate can be used to identify a user – a form of identification/authorisation – sometimes used as an alternative to passwords – based on asymmetric cryptography • Concept: – A Certification Authority (CA), aka trusted third party issues you with your own digital certificate – The CA is vouching that they believe you to be who you claim to be – Common CA companies are Verisign, Entrust – Typically require some form of real ID before they issue you with a valid certificate © Copyright UTS Faculty of Information Technology – Security 19

Digital Certificate contents Faculty of Information Technology • A digital certificate contains: – – Digital Certificate contents Faculty of Information Technology • A digital certificate contains: – – your public key serial number valid period etc. • A digital certificate is: – digitally signed by the CA – encrypted with your own public key © Copyright UTS Faculty of Information Technology – Security 20

Digital Certificate – application Faculty of Information Technology • When an application receives a Digital Certificate – application Faculty of Information Technology • When an application receives a certificate, it: – Verifies the digital signature of the CA by attempting to decrypt the certificate using the CA's public key – The application will keep a local copy of the public keys of well-known CAs so it can do this. – Verifies the data contained in the certificate (expiry date, domain name/email address to whom the certificate was issued, etc) – Extracts your public key • The application can then send you messages encrypted with your public key – i. e. confidentiality function © Copyright UTS Faculty of Information Technology – Security 21

SSL / TLS Faculty of Information Technology • SSL = Secure Sockets Layer • SSL / TLS Faculty of Information Technology • SSL = Secure Sockets Layer • TLS = Transport Layer Security • Basic concept: – server sends certificate to client, to establish its identity – client may optionally send certificate to server, to establish client's identity – once authentication is complete, the client and server agree upon a "session key" – a symmetric key used only for the current session – key exchange is done using asymmetric encryption – data exchange is done using symmetric encryption © Copyright UTS Faculty of Information Technology – Security 22

Topics Faculty of Information Technology • Security background – – Confidentiality, Integrity, Availability Authentication, Topics Faculty of Information Technology • Security background – – Confidentiality, Integrity, Availability Authentication, Authorisation, Non-repudiation Cryptography primer Digital certificates • Basic Java security – JCA, JCE, JSSE, JAAS • Enterprise Java security – Declarative vs Programmatic © Copyright UTS Faculty of Information Technology – Security 23

Basic Java Security Faculty of Information Technology • Java 1. 0 – sandbox model Basic Java Security Faculty of Information Technology • Java 1. 0 – sandbox model for applets – no flexibility • Java 1. 1 – extended to allow "trusted" code to run outside sandbox – still fairly limited flexibility • Java 1. 2 (Java 2) core security – configurable policies based on codebase and signer – for a particular application, can limit resources accessible to that application © Copyright UTS Faculty of Information Technology – Security 24

Java security architecture Java Authentication and Authorization Service (JAAS) Java Secure Socket Extension (JSSE) Java security architecture Java Authentication and Authorization Service (JAAS) Java Secure Socket Extension (JSSE) Core Java 2. 0 Security Architecture Faculty of Information Technology Java Cryptography Extension (JCE) Java Cryptography Architecture (JCA) Java 2. 0 Platform © Copyright UTS Faculty of Information Technology – Security 25

Core Java 2 Security Faculty of Information Technology • When a class is loaded Core Java 2 Security Faculty of Information Technology • When a class is loaded into the JVM, it goes to: – Class Loader – Byte code verifier – Security Manager / Access Controller • The Security Manager / Access Controller rely on the definition of: – permissions – policies – protection domains defined declaratively in a policy file © Copyright UTS Faculty of Information Technology – Security 26

Java Cryptography Architecture Faculty of Information Technology • JCA provides supporting classes for underlying Java Cryptography Architecture Faculty of Information Technology • JCA provides supporting classes for underlying cryptography mechanisms • Concepts like: – – Key (and Private. Key, Public. Key) Principal Certificate Policy • Provides an architecture through which different crypto implementations can be plugged in • Doesn't actually do the encryption itself © Copyright UTS Faculty of Information Technology – Security 27

Java Cryptography Extension Faculty of Information Technology • JCE provides some algorithms for actually Java Cryptography Extension Faculty of Information Technology • JCE provides some algorithms for actually performing encryption • Defined separately to JCA because of U. S. (and other) export restrictions © Copyright UTS Faculty of Information Technology – Security 28

Java Secure Socket Extension Faculty of Information Technology • JSSE is the Java interface Java Secure Socket Extension Faculty of Information Technology • JSSE is the Java interface to the SSL/TLS protocol • Allows all SSL/TLS features: – exchange of certificates for authentication – encrypted data exchange for confidentiality, integrity • Allows SSL/TLS for more than just HTTP – IIOP for CORBA exchanges – WTLS for crypto in Wireless contexts © Copyright UTS Faculty of Information Technology – Security 29

Authentication & Authorisation Faculty of Information Technology • JAAS provides support for: – login Authentication & Authorisation Faculty of Information Technology • JAAS provides support for: – login authentication – ACL-based authorisation • Uses "Pluggable Authentication Module" (PAM) architecture – like Solaris, Linux – allows different underlying authentication mechanisms, e. g. passwords, smart cards, etc. © Copyright UTS Faculty of Information Technology – Security 30

JAAS classes Faculty of Information Technology • java. security. Principal – a user identity JAAS classes Faculty of Information Technology • java. security. Principal – a user identity • javax. security. auth. Subject – represents an individual or organisation with multiple principals • javax. security. auth. login. Login. Context – an API for Subjects (Principals) to log in or log out • javax. security. auth. spi. Login. Module – interface that login service providers must follow • javax. security. auth. login. Configuration – allows configuration of multiple Login. Modules © Copyright UTS Faculty of Information Technology – Security 31

JAAS client example Faculty of Information Technology try { // Create Login. Context login. JAAS client example Faculty of Information Technology try { // Create Login. Context login. Context= new Login. Context("Sample. Login. Module, " new My. Callback. Handler()); // Attempt authentication login. Context. login (); // Retrieve authenticated Subject and perform. Sample. Action as Subject subject = login. Context. get. Subject); ( Sample. Action sample. Action= new Sample. Action(); Subject. do. As(subject sample. Action , ); } catch (Login. Exceptionle) { System. out. println("Errorlogging in. "); } © Copyright UTS Faculty of Information Technology – Security 32

Topics Faculty of Information Technology • Security background – Identification, Access Control, Integrity, Confidentiality, Topics Faculty of Information Technology • Security background – Identification, Access Control, Integrity, Confidentiality, non-repudiation – Cryptography primer – Digital certificates • Basic Java security – JCA, JCE, JSSE, JAAS • Enterprise Java security – Declarative vs Programmatic © Copyright UTS Faculty of Information Technology – Security 33

Enterprise application security Faculty of Information Technology • Containers provide access to security services Enterprise application security Faculty of Information Technology • Containers provide access to security services – web containers provide access to HTTP security services – EJB containers provide access to EJB security services • Security may be implemented: – declaratively: let the container do most of the work – programmatically: you write code to do the work © Copyright UTS Faculty of Information Technology – Security 34

Security Points Faculty of Information Technology Security Infrastructure (App Server *may* use JAAS to Security Points Faculty of Information Technology Security Infrastructure (App Server *may* use JAAS to access) http/https Web Tier (Servlets/JSP) BASIC, Form, Mutual-SSL Rmi/ Business Logic (Vendor A) IIOP Resource Tier EJBs rmi/iiop new Initial. Context(props) JAAS Business Logic (Vendor B) EJBs John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 35

Security Infrastructure Faculty of Information Technology • J 2 EE specs dictate little concerning Security Infrastructure Faculty of Information Technology • J 2 EE specs dictate little concerning actual security implementation. • Many implementations possible – X. 509 Certificates/LDAP/etc. – Kerberos • Application server is responsible for ‘adapting’ the security infrastructure in the deployment environment to the J 2 EE application’s needs – Every App server does this differently John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 36

Weblogic Security Infrastructure Faculty of Information Technology • Weblogic provides extensions to J 2 Weblogic Security Infrastructure Faculty of Information Technology • Weblogic provides extensions to J 2 EE 1. 4 – Users and Groups configured using console or Mbeans – Defines Service Provider Interface so various security implementations can be overridden • • Authentication Identity Assertion Authorization Auditing Adjudication Role Mapping Key. Store Credential Mapper John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 37

WL Security Infrastructure (Cont) Faculty of Information Technology • Contains an embedded LDAP adapter WL Security Infrastructure (Cont) Faculty of Information Technology • Contains an embedded LDAP adapter – Adapters to most commercial LDAP servers also • Can define advanced policies for access to resources – times of day, from where, etc. • Adds concepts of hierarchy of roles (“groups” ) to standard security model John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 38

Enterprise applications & Java 2 Faculty of Information Technology • Java 2 security services Enterprise applications & Java 2 Faculty of Information Technology • Java 2 security services provide a foundation for the container, but your applications may not necessarily need to use them – Container manages these features for you • e. g. to use SSL, you configure the web container for SSL support, you don't use JSSE • JAAS ? – at the moment, designed for client-side authentication, for Java client applications (note: not web clients) – maybe in future used for authentication between web and EJB servers © Copyright UTS Faculty of Information Technology – Security 39

Web tier Security Points Faculty of Information Technology Security Infrastructure (App Server *may* use Web tier Security Points Faculty of Information Technology Security Infrastructure (App Server *may* use JAAS to access) http/https Web Tier (Servlets/JSP) BASIC, Form, Mutual-SSL Rmi/ Business Logic (Vendor A) IIOP Resource Tier EJBs rmi/iiop new Initial. Context(props) JAAS Business Logic (Vendor B) EJBs John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 40

Web Tier Security Faculty of Information Technology • Authentication – BASIC – Form – Web Tier Security Faculty of Information Technology • Authentication – BASIC – Form – Client X. 509 Certificate • Confidentiality and Message Integrity – Can require communication to take place over SSL with element • Can be declarative or programmatic John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 41

Declarative web security Faculty of Information Technology <login-config> <auth-method>BASIC</auth-method> <realm-name>My Application</realm-name> </login-config> <security-role> <role-name>sales</role-name> Declarative web security Faculty of Information Technology BASIC My Application sales Hello. World. Servlet /Hello. World sales © Copyright UTS Faculty of Information Technology – Security 42

Declarative web security (2) Faculty of Information Technology • <login- onfig c > – Declarative web security (2) Faculty of Information Technology • – specifies what style of login to use. Some options: • BASIC – HTTP Basic (popup dialog) authentication • FORM – uses a user-written HTML form • CLIENT-CERT – requires client certificate to be presented • – just defines a role name that will be used later • – defines what to protect: – defines authentication needed: – defines confidentiality needed: © Copyright UTS Faculty of Information Technology – Security 43

Programmatic web security Faculty of Information Technology <!-- all of previous web. xml, plus Programmatic web security Faculty of Information Technology Hello. World Hello. World My. Sales. Users sales © Copyright UTS Faculty of Information Technology – Security 44

Programmatic web security (2) Faculty of Information Technology import java. security. Principal; public class Programmatic web security (2) Faculty of Information Technology import java. security. Principal; public class Hello. World. Servlet extends Http. Servlet { public void do. Get (Http. Servlet. Request req, Http. Servlet. Response res) throws. . . {. . . String username = null; Principal p = req. get. User. Principal(); if (p != null) { username = p. get. Name(); } if (username == "My. Sales. Users" ) { // Sales-specific code } © Copyright UTS Faculty of Information Technology – Security 45

Declarative vs. programmatic Faculty of Information Technology • Declarative security is better – let Declarative vs. programmatic Faculty of Information Technology • Declarative security is better – let the container manage the security – changing security doesn't require changing compiled code – however, it is coarse-grained: • granularity is on a per-file (servlet, JSP or HTML/GIF/JPG) level • Programmatic security gives you more control – but may mean introducing business logic into presentation tier – bad! © Copyright UTS Faculty of Information Technology – Security 46

EJB Security points Faculty of Information Technology Security Infrastructure (App Server *may* use JAAS EJB Security points Faculty of Information Technology Security Infrastructure (App Server *may* use JAAS to access) http/https Web Tier (Servlets/JSP) BASIC, Form, Mutual-SSL Rmi/ Business Logic (Vendor A) IIOP Resource Tier EJBs rmi/iiop new Initial. Context(props) JAAS Business Logic (Vendor B) EJBs John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 47

EJB Security Faculty of Information Technology • Authentication – validates the identity of the EJB Security Faculty of Information Technology • Authentication – validates the identity of the user – implemented through username/password logins, ID Cards, security certificates, etc. – Technique used not covered by EJB Specification • Authorization/Access Control – controls what a user can and cannot do within the system • Secure Communications – ensuring the privacy of a communications – implemented through private communication (infrequently) channels or (more commonly) encryption – not covered by EJB Specification John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 48

Authentication Faculty of Information Technology • EJB external clients (eg: RMI) – Specify principal Authentication Faculty of Information Technology • EJB external clients (eg: RMI) – Specify principal and password properties when creating JNDI initial context – Use jndi. properties or when you use Initial. Context – set java. naming. security. authentication=none | simple | strong – set java. naming. security. principal=userid java. naming. security. credentials=password|key – Or use JAAS with a client-login module John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 49

Authentication -2 Faculty of Information Technology • Web services clients – can also use Authentication -2 Faculty of Information Technology • Web services clients – can also use basic authentication – Set javax. xml. rpc. Stub. USERNAME_PROPERTY, PASSWORD_PROPERTY properties before executing Stub – Similar for Dynamic Invocation Clients (use javax. xml. rpc. Call. properties) • Web Clients – Authenticated with FORM, Basic, or certificates John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 50

Authentication -3 Faculty of Information Technology • EJB Spec requires that every client access Authentication -3 Faculty of Information Technology • EJB Spec requires that every client access be associated with a security identity – user or role – get. Caller. Principal always returns a valid principal • User logs into EJB System and authenticated through an implementation-specific method • EJB Server passes security identity along with method invocation • EJB objects or EJB homes check access John Hopkins University, Enterprise Java course 605. 97 © Copyright UTS Faculty of Information Technology – Security 51

Declarative EJB security Faculty of Information Technology <enterprise-beans> <session>. . . <ejb-name>My. Test. EJB</ejb-name>. Declarative EJB security Faculty of Information Technology . . . My. Test. EJB. . . sales sales My. Test. EJB update. Sales. Figures © Copyright UTS Faculty of Information Technology – Security 52

Declarative EJB security (2) Faculty of Information Technology • <security-role> – just defines a Declarative EJB security (2) Faculty of Information Technology • – just defines a role name that will be used later • – allows you to only permit certain users (roles) to invoke certain EJB methods – can use * to set the default security for all methods on an EJB, unless specifically overridden • Container may allow you to map into specific users as defined on the server – Web. Logic does, in weblogic-ejb. xml © Copyright UTS Faculty of Information Technology – Security 53

Ejb 3 Faculty of Information Technology Caller principal: • Declare the security roles via Ejb 3 Faculty of Information Technology Caller principal: • Declare the security roles via annotation – @Declare. Roles(({HR_Manager, HR_Admin}) • You can set the role that your method/class runs under: – @Run. As(HR_Manager) • You can choose which method/class is authorised: – @Roles. Allowed(HR_Manager) – @Permit. All, @Deny. All © Copyright UTS Faculty of Information Technology – Security 54

EJB 3 security example Faculty of Information Technology @Roles. Allowed(HR_Manager) @Stateless public class Payroll. EJB 3 security example Faculty of Information Technology @Roles. Allowed(HR_Manager) @Stateless public class Payroll. Bean implements Payroll { public void set. Salary(int emp. Id, double salary) {. . . } @Roles. Allowed({HR_Manager, HR_Admin}) public int get. Salary(int emp. Id) {. . . } } © Copyright UTS Faculty of Information Technology – Security 55

Programmatic EJB security Faculty of Information Technology <!-- all of previous ejb-jar. xml, plus Programmatic EJB security Faculty of Information Technology My. Test. EJB. . . My. Sales. Users sales . . . © Copyright UTS Faculty of Information Technology – Security 56

Programmatic EJB security (2) Faculty of Information Technology import java. security. Principal; public class Programmatic EJB security (2) Faculty of Information Technology import java. security. Principal; public class My. Test. EJB implements Session. Bean { public void update. Sales. Figures(. . . ) {. . . String username = null; Principal p = session. Context. get. Caller. Principal (); if (p != null) { username = p. get. Name(); } if (username == "My. Sales. Users" ) { // Sales-specific code } © Copyright UTS Faculty of Information Technology – Security 57

Container security support Faculty of Information Technology • How the container chooses to implement Container security support Faculty of Information Technology • How the container chooses to implement security is not specified by J 2 EE • Different containers may support retrieving authentication information from different sources – – filesystem (stored in a file) LDAP directory Database server Operating system (NT or Unix login information) • Different containers may support different SSL implementations – e. g. with different supported ciphers © Copyright UTS Faculty of Information Technology – Security 58

Summary Faculty of Information Technology • Java security based on traditional foundations • JAAS, Summary Faculty of Information Technology • Java security based on traditional foundations • JAAS, JSSE, JCE are more for client apps – but maybe relevance to enterprise apps in future, especially JAAS • Two main aspects of Java enterprise security are: – authentication/authorisation (container-managed) – cryptography (SSL, certificates) • Can implement declaratively or programmatically – declaratively is easier/better when you can do it © Copyright UTS Faculty of Information Technology – Security 59