59264945-Websphere-Security.pdf
- 1. © Copyright IBM Corporation 2006 Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.2 WebSphere security IBM Confidential
- 2. © Copyright IBM Corporation 2006 Unit objectives After completing this unit, you should be able to: ●Describe how authentication and authorization are handled by WebSphere Application Server ●Define single sign-on ●Describe J2EE security ●Distinguish between authentication and authorization ●Describe how global security is configured
- 3. © Copyright IBM Corporation 2006 This is the customer. The client can be either a single user PC or a whole company. The devices are specified when necessary. This is the router to the Internet. It typically provided by an ISP (Internet Service Provider). This model, however, can apply to a corporate Intranet. This router separates the internal network from the outside network. This is the company's Web server. It provides the universal access to the company's business logic. It allows browser access to the company's corporation. Above the Web server is the organization's company router/access device. This is the business logic. These applications have access to the databases and provide the company business rules. This is the company's data. Ultimately this is the information the company wishes to share with the customer. This data can be centralized or distributed. For this example, the data is accessed through business logic. Firewall Client Apps Data (Internet) Web Servers Basic security end-to-end model Domain Firewall (DMZ) (Intranet)
- 4. © Copyright IBM Corporation 2006 WebSphere Application Server security overview OS Security JVM Security Java2 Security CORBA Security J2EE SecurityAPI WebSphere Security *HTML *JSPs, Servlets, EJBs Platform Security Java Security WebSphere Security WebSphere Resources ƒSecurity can be applied at different levels
- 5. © Copyright IBM Corporation 2006 WebSphere security service – Big picture ●Security service runs locally in each process (Deployment Manager, Node Agent, and Application Server) – Security workload not bottlenecked to a single process – Security service failure only affects a single process ●Separation of authentication mechanism and user registry – Only one authentication mechanism and registry can be enabled at a time Node Agent Deployment Manager XML files Administrator App Server Security Service Security Service Security Service XML files App Server Security Service XML files Node Agent Security Service App Server Security Service XML files User Registry
- 6. © Copyright IBM Corporation 2006 Authentication and access control ●Authentication –Who are you? ●Authorization –What are you allowed to do? App Server Security Service XML files User Registry Web Container Web Container .ear Authentication Authorization
- 7. © Copyright IBM Corporation 2006 Client Server User Registry Authentication basic steps Request Challenge UserID and passwordd A u t h e n t i c a t i o n
- 8. © Copyright IBM Corporation 2006 Authentication ●Authentication: Tell a server who you are –Challenge mechanism (how to obtain authentication data: basic authentication, certificate-based, form- based) –Authentication mechanism User registry (associates credentials with principal: local OS, LDAP, custom, federated) Challenge Mechanism Challenge user Authentication Mechanism Authentication Data (uid/pw, cert, token) Authentication Data Credentials Authenticated Credentials User Registry
- 9. © Copyright IBM Corporation 2006 Basic Authentication: •Password transmitted with encoding •Authentication stored at server •Web browser validates server certificate Web Server Web Browser 3. Request Web Page 5. userid = peter password = pumpkin 4. 401 and server certificate Admin 1. Register user userid = peter password = pumpkin Authentication DB 6. Check Password Basic authentication challenge types 4. Server certificate and Request for client certificate Web Server Web Browser 3. Request Web Page Admin 1. Request and receive server certificate Authentication DB 2. Request and receive certificate 5. Send client certificate Certificate Authentication: •Server requests certificate from browser •Browser validates server’s certificate •Browser sends client certificate to server •Server validates client certificate 2. Tell user UserID = peter Password = pumpkin
- 10. © Copyright IBM Corporation 2006 Registries and authentication mechanisms Local OS User Registry Local OS Authentication Layer LTPA Authentication Layer WebSphere Runtime WebSphere Provided Stand-alone LDAP Pluggable Custom Authentication Layer Custom Provider Custom User Registry Authentication Calls Security Server File Based LDAP1 LDAP2 Federated
- 11. © Copyright IBM Corporation 2006 WebSphere administrative and application security ●WebSphere administrative security is enabled by default during profile creation ●Application and Java 2 security are disabled by default
- 12. © Copyright IBM Corporation 2006 Federated repositories ●The installation wizard and profile management tool have a default of enabling administrative security – The default repository type is a file based federated repository ●Federated repositories enables the use of multiple repositories with WebSphere Application Server – Can be file-base, LDAP, multiple LDAPs or a sub-tree of an LDAP – Defined and theoretically combined under a single realm – All of the user repositories that are configured under the federated repository functionality are invisible to WebSphere Application Server ●Federation capabilities provided by the VMM (Virtual Member Manager)
- 13. © Copyright IBM Corporation 2006 wsadmin Federated repositories: architecture overview Application Local OS CUR VMM LDAP User Registries LDAP DB File Custom Adaptor Adaptor Adaptor Adaptor Authentication (JAAS) Administrative Console VMM Runtime APIs VMM Configuration APIs Administrative Command Framework Repository SPI Property Ext SPI Adaptor DB WebSphere Application Server V6.1 Application Server Security VMM User Management VMM Configuration Management VMM = Virtual Member Manager
- 14. © Copyright IBM Corporation 2006 IBM Tivoli Directory Server IBM SecureWay Directory Sun ONE IBM Lotus Domino Microsoft Active Directory Others (using custom config) not "supported" User Registries Supported by WebSphere Application Server LDAP Local OS NT Domain, NT WorkGroup, Windows 2000 AIX Solaris HP-UX Linux OS/400 User registry support Novell eDirectory
- 15. © Copyright IBM Corporation 2006 Custom registry ●Allows custom implementation of user registry ●Some possible implementations: – Database – Flat file – OS-based, with additional custom logic – Use other, not directly supported, registries ●WebSphere provides: – Base types • Implementing classes extend the com.ibm.websphere.security.UserRegistry class – Working sample implementation • com.ibm.websphere.security.FileRegistrySample
- 16. © Copyright IBM Corporation 2006 Custom registry – Configuration ●Configured from administrative console: – Security Æ Secure administration, application, and infrastructure – Select Standalone custom registry from the Available realm definitions – Click Configure • User ID and password must exist • Classname must be implemented and in classpath
- 17. © Copyright IBM Corporation 2006 Authentication mechanisms ●For simple, non-distributed, single application server environments ●Does not support forwardable credentials or single sign-on (SSO) ●Caller identity is not forwarded from client on one server to EJB on another server - What gets forwarded in unauthenticated credential which may fail on the receiving server Simple WebSphere Authentication Mechanism (SWAM) - Not available and not needed in WebSphere Application Server V6 Network Deployment and higher packages - Depricated in V6.1 ●For distributed, multiple application server environments ●Support forwardable credentials or single sign-on (SSO) through cryptography ●Requires all the servers authentication registry to be a centrally shared registry like LDAP ●Uses cryptographic keys (LTPA keys) to encrypt and decrypt user data that passes between the servers –If Servers are in different cell, the LTPA keys need to be shared •Generate, Export and Import LTPA keys in the admin console –All servers in the domain must be synchronized Local Third Party Authentication (LTPA) mechanism Available on all platforms and packages Intended Use and Supported Package Authentication Mechanism
- 18. © Copyright IBM Corporation 2006 WebSphere Application Server Stored User Information Enterprise Enterprise JavaBeans JavaBeans Server Server 1. Request 2. Challenge User for Authentication 3. User Authenticates 7. Create authToken cookie; serve the request Security Server that contains the Authentication Token Server 4. Authenticate (authenticationData) 6. Issue Authentication Token 5.Verify userid and password using LDAP user registry 8. Pass User Credentials (token) to EJS when invoking methods on EJBs 9. Pass token over Secure Association Enterprise Enterprise JavaBeans JavaBeans Server Server LTPA and LDAP zAllows a user's identity to be passed around the distributed network
- 19. © Copyright IBM Corporation 2006 Delegation X can run as: Option 1. Client Option 2. Server 1 Option 3. Specified identity id = client id = X client server 1 server 2
- 20. © Copyright IBM Corporation 2006 Single sign-on (SSO) ●Once a client has a valid LTPA token, they do not need to reauthenticate within a cell ●SSO is on by default ●Issues cookies to Web browser to track user authentication information ●Provides for SSO within or even between WebSphere cells
- 21. © Copyright IBM Corporation 2006 Security wizard A security wizard exists to help step through the process of setting up initial security
- 22. © Copyright IBM Corporation 2006 Security wizard – step 1
- 23. © Copyright IBM Corporation 2006 Security wizard – step 2
- 24. © Copyright IBM Corporation 2006 Security wizard – step 3
- 25. © Copyright IBM Corporation 2006 Security wizard – step 4
- 26. © Copyright IBM Corporation 2006 userX, opY userX?? Rules opY??? User Registry decide client server Authorization ●Authorization involves granting trusted principals permission to perform actions on resources (Web pages, servlets, JSPs and EJBs) ●Control access to resources –Security lookup (by server) •Determine security privileges for principal •Information stored in registry –Rule enforcement (by server) •Obtain rules from registry •Given privileges of principal and rules, determine access
- 27. © Copyright IBM Corporation 2006 J2EE security roles: Application authorization ●Authorization is performed using the J2EE security roles –Specify security at an abstract level without knowledge of actual users and groups ●Security roles are then applied to the Web and EJB application components –Web URIs or EJB methods ●Binding of the users and groups to the J2EE security roles is usually done at the application install time Web Module Servlets, JSPs, HTMLs EJB Module EJBs J2EE Security Roles Users/ Groups Binding EAR file
- 28. © Copyright IBM Corporation 2006 Actual Users and Groups J2EE Security Roles Securing J2EE application artifacts Enterprise Java Bean (EJB) Web Components HTML, GIFs, and so on. EJB Method EJB Method EJB Method Jack Bob Mary Clients Manager Teller Customer Servlet JSP Usually by Assembler or Developer Usually by Deployer Security Binding Security Permissions
- 29. © Copyright IBM Corporation 2006 Applying J2EE security with AST ●J2EE security can be applied to resources within an application – J2EE security roles are defined in the application deployment descriptor – Servlets and JSPs are protected with security constraints, which are mapped to the security roles – EJBs are protected with method permissions, which are mapped to the security roles ●The J2EE security roles are then mapped to actual users and groups during installation of the application
- 30. © Copyright IBM Corporation 2006 Applying J2EE security roles using the console ●The mapping of users and groups to J2EE security roles can take place during or after application installation – After installation, using the administrative console, go to the application and under Detailed Properties, select Security role to user/group mapping – Select the role and either • Lookup and apply users or groups • Map to Everyone • Map to All authenticated
- 31. © Copyright IBM Corporation 2006 Console security ●Defines which roles have access to the administrative tools –Monitor: Least privileged; allows a user to view the WebSphere configuration and current application server state –Configurator: Monitor privilege plus the ability to change the WebSphere configuration. –Operator: Monitor privilege plus the ability to change runtime state, such as starting or stopping servers –Administrator: Operator, configurator, and iscadmins privilege, plus additional privileges granted solely to the administrator role, such as: • Modifying the primary administrative user and password • Mapping users and groups to the administrator role • Enabling or disabling administrative and Java 2 security Configurator Operator Monitor Administrator AppSrv C:> wsadmin Security Check
- 32. © Copyright IBM Corporation 2006 Additional console security roles ●iscadmins (Integrated Solutions Console) – Only available for administration console users – Allows a user to manage users and groups in the federated repositories ●Deployer – Only available for wsadmin users (not administration console) – Allows a user to change configuration and runtime state on applications using wsadmin ●Admin Security Manager – Only available for wsadmin users – Allows a user to map users to administrative roles using wsadmin – When restricted access to resource authentication data is in effect, users can also manage authorization groups
- 33. © Copyright IBM Corporation 2006 Console security – creating users and groups ●To set up console security – Turn on administrative security – Create console users and/or groups – Map users and groups to administrative roles
- 34. © Copyright IBM Corporation 2006 Console security – mapping users and groups ●To set up console security – Turn on administrative security – Create console users and groups – Map users and groups to administrative roles
- 35. © Copyright IBM Corporation 2006 JVM Full Access to Resources Sandbox Restricted Access Security Manager System Resources (such as files and network connections) Local Code Remote Code JVM Full Access to Resources Sandbox Restricted Access Security Manager System Resources (such as files and network connections) Local Code Remote Code Trusted Signed Code Java security model ●Java 1.0 (sandbox model): – Downloaded code (untrusted) runs in a Sandbox (restricted environment) – Application code (local Java classes) have full access to resources (trusted and no protection) ●Java 1.1 (signed code): – Extends 1.0 Sandbox Model, introduce signed code, digitally signed remote code is treated like local code if public key used to verify the signature is trusted.
- 36. © Copyright IBM Corporation 2006 Java 2 security overview ●Protects the system from the applications ●Provides an access control mechanism to manage the application’s access to system level resources – File I/O, network connections (sockets), property files, and so forth – Policy-based ●Policies define a set of permissions available from various signers and/or code locations – Stored in policy files ●All Java code runs under a security policy – Grants access to certain resources ●Can be turned on or off independently of administrative security ●Java code needs access to certain system resources ●Java code needs to get the permission from Java 2 access control ●Access control looks at the Java 2 policy files to determine if the requesting Java code has the appropriate permission Java Class System Resource Protection Domain Java 2 Security Permissions Security Manager Access Controller Java 2 Policy Files JVM
- 37. © Copyright IBM Corporation 2006 Enabling Java 2 security Can be enabled and disabled independently of administrative and application security
- 38. © Copyright IBM Corporation 2006 What is SSL? ●SSL stands for Secure Sockets Layer ●SSL provides connection security through: – Communication privacy -- the data on the connection is encrypted – Communication integrity -- the protocol includes a built-in integrity check – Authentication -- the client knows who the server is – SSL creates a VPN, securing the data using a combination of symmetric and asymmetric encryption
- 39. © Copyright IBM Corporation 2006 Symmetric key encryption ●Symmetric or secret key technology is a model in which two parties have a shared secret ●The same key is used for both encryption and decryption.
- 40. © Copyright IBM Corporation 2006 Asymmetric key encryption ●Public key cryptography –Two keys that are cryptographically related •Public key (Can be shared with everyone) •Private key (Must never be shared; possession is proof) –Keys are asymmetric •Given message is encrypted with one key and decrypted with the other
- 41. © Copyright IBM Corporation 2006 How does SSL work? ●SSL uses a combination of asymmetric and symmetric encryption to create a session between the client and server. –Asymmetric encryption is used to negotiate a session key (shared secret) • Asymmetric encryption is slow but does not require a shared secret –Symmetric encryption is used to transfer data between the client and server • Symmetric encryption is fast but requires a shared secret Client 1 - Client Requests SSL Connection 2 -Server presents certificate 3 - Client verifies server certificate 6 - HTTPS communications Server 4 – Client generates a session key, encrypts it with the server’s public key 5 – Using the session key, client and server switch to symmetric key encryption
- 42. © Copyright IBM Corporation 2006 Server B Server A yVerifies identities of Server A and Server B yIssues a certificate vouching for Server A and Server B Mutual trust based on certificates Server A Certificate Server B Certificate Client trusts server based on certificate Certificate Authority Client C Certificates and certificate authority (CA)
- 43. © Copyright IBM Corporation 2006 SSL within WebSphere Application Server ●SSL can be used to secure network traffic for a number of links –From the client to the Web server –From the plug-in to the application server –Other network links can also be secured (LDAP and others) ●ikeyman can be used to create and manage the necessary keys and keyrings
- 44. © Copyright IBM Corporation 2006 Creating key rings and certificates ●The tool for manipulating the key rings is called iKeyman –Creates keyrings –Requests and imports CA certificates –Creates self-signed certificates ●Beware: There are multiple versions of iKeyman shipping with different products. They are not always compatible.
- 45. © Copyright IBM Corporation 2006 SSL between plug-in and the application server ●SSL is enabled by default between the plug-in and the application server ●To configure a new SSL connection –Create new keyring –Create new certificates –Exchange the signing certificates between the plug-in and the application server
- 46. © Copyright IBM Corporation 2006 Cell keyrings and truststores … Cell Deployment Manager … NodeAgent V6.1 Node App Server App Server … NodeAgent V6.1 Node App Server App Server ● Each managed process will have a self-signed certificate – The default lifetime of the certificates is one year – The default is for the certificates to be self managed – As the certificates approach their expiration (60 days prior), a warning is generated and the certificate is automatically replaced ● All signing certificates for the cell are put into a cell wide truststore – By sharing a single trust store, the any member of the cell can securely communicate with any other member of the cell
- 47. © Copyright IBM Corporation 2006 Managing WebSphere keyrings Keyrings and certificates for the cell can be managed directly from the console
- 48. © Copyright IBM Corporation 2006 Plug-in keyrings ●A self-signed certificate is generated by WebSphere for each defined Web server node – A customer generated certificate can also be used ●The current certificate needs to be propagated to the Web server – During the plug-in install a temporary certificate/keyring is made available for the Web Server – This temporary keyring needs to be replaced in order to be able to communicate securely with the cell ●IMPORTANT: The new keyring includes signing certificates for every node in the cell – If any nodes are subsequently added to your cell or any certificates for the nodes are updated, the Web server keyrings will need to be updated Web Server Plug-in Module S2 Propagation OS Deployment Manager … NodeAgent App Server App Server Web server node keyring
- 49. © Copyright IBM Corporation 2006 IBM Http Server keyring propagation ● The initial keyring for IBM Http Server servers can be remotely propagated – This does up automatically update the keyring in the future – The keyring is not updated after initial creation
- 50. © Copyright IBM Corporation 2006 Checkpoint questions 1. Which type of security restricts access to the application A. Administrative security B. J2EE security C. Java 2 security D. File system security 2. Which type of security restricts access to the operating system A. Administrative security B. J2EE security C. Java 2 security D. File system security 3. Which type of security restricts access to the console A. Administrative security B. J2EE security C. Java 2 security D. File system security
- 51. © Copyright IBM Corporation 2006 Checkpoint solutions 1. Which type of security restricts access to the application B. J2EE security 2. Which type of security restricts access to the operating system C. Java 2 security 3. Which type of security restricts access to the console A. Administrative security
- 52. © Copyright IBM Corporation 2006 Unit summary Having completed this unit, you should be able to: ●Describe how authentication and authorization are handled by WebSphere Application Server ●Define single sign-on ●Describe J2EE security ●Distinguish between authentication and authorization ●Describe how global security is configured
- 53. © Copyright IBM Corporation 2006 Lab exercise Exercises 12 – Configuring SSL 13 – Enabling WebSphere and J2EE Security