A resource environment reference maps a logical name used by the client application to the physical name of an object For more information, see Mapping logical names of environment resources to their physical names. Security The following information provides an overview of security in WebSphere Application Server I BM Web Sphere Application Server provides security infrastructure and mechanisms to protect sensitive Java 2 Platform, Enterprise Edition(J2EE) resources and administrative resources. It also addresses enterprise end-to-end security requirements on · Authentication Resource access control Privacy I BM Web Sphere Application Server security is based on industry standards and has an open architecture that ensures secure connectivity and interoperability with Enterprise Information Systems(ElS)including Database 2(DB2 Information Management System(IMS) MQ Series Web Sphere Application Server also supports other security providers including IBM Tivoli Access Manager(Policy Director) erse secure proxy server including Based on industry standards I BM Web Sphere Application Server provides a unified, policy-based, and permission-based model for securing Web resources, Web service endpoints, and enterprise JavaBeans according to J2EE specifications. Specifically, WebSphere Application Server complies with J2EE specification Version 1.4 and has passed the J2EE Compatibility Test Suite WebSphere Application Server security is a layered architecture built on top of an operating system platform, a Java virtual machine(JVM), and Java 2 security. This security model employs a rich set of security technology including the Java 2 security model, which provides policy-based, fine-grained, and permission-based access control to system resources Common Secure Interoperability Version 2(CSlv2) security protocol, in addition to the Secure Authentication Services(SAS)security protocol. Both protocols are supported by prior WebSphere Application Server releases. CSlv2 is an integral part of the J2EE 1.4 specification and is essential for teroperability among application servers from different vendors and with enterprise CORBA services Java Authentication and Authorization Service(JAAS) programming model for Java applications servlets, and enterprise beans. J2EE Connector architecture for plugging in resource adapters that support access to Enterprise Information Systems Chapter 1 Overview and new features: Administering 9
A resource environment reference maps a logical name used by the client application to the physical name of an object. For more information, see Mapping logical names of environment resources to their physical names. Security The following information provides an overview of security in WebSphere Application Server. IBM WebSphere Application Server provides security infrastructure and mechanisms to protect sensitive Java 2 Platform, Enterprise Edition (J2EE) resources and administrative resources. It also addresses enterprise end-to-end security requirements on: v Authentication v Resource access control v Data integrity v Confidentiality v Privacy v Secure interoperability IBM WebSphere Application Server security is based on industry standards and has an open architecture that ensures secure connectivity and interoperability with Enterprise Information Systems (EIS) including: v Database 2™ (DB2®) v CICS® v Information Management System (IMS™) v MQ Series v Lotus® Domino® v IBM Directory WebSphere Application Server also supports other security providers including: v IBM Tivoli® Access Manager (Policy Director) v Reverse secure proxy server including WebSEAL Based on industry standards IBM WebSphere Application Server provides a unified, policy-based, and permission-based model for securing Web resources, Web service endpoints, and enterprise JavaBeans according to J2EE specifications. Specifically, WebSphere Application Server complies with J2EE specification Version 1.4 and has passed the J2EE Compatibility Test Suite. WebSphere Application Server security is a layered architecture built on top of an operating system platform, a Java virtual machine (JVM), and Java 2 security. This security model employs a rich set of security technology including the: v Java 2 security model, which provides policy-based, fine-grained, and permission-based access control to system resources. v Common Secure Interoperability Version 2 (CSIv2) security protocol, in addition to the Secure Authentication Services (SAS) security protocol. Both protocols are supported by prior WebSphere Application Server releases. CSIv2 is an integral part of the J2EE 1.4 specification and is essential for interoperability among application servers from different vendors and with enterprise CORBA services. v Java Authentication and Authorization Service (JAAS) programming model for Java applications, servlets, and enterprise beans. v J2EE Connector architecture for plugging in resource adapters that support access to Enterprise Information Systems. Chapter 1. Overview and new features: Administering 9
The standard security models and interfaces that support secure socket communication, message encryption, and data encryption are the Java Secure Socket Extension (JSSE) and the Java Cryptographic Extension ( JCE) Open architecture paradigm An application server plays an integral part in the multiple-tier enterprise computing framework. IBM WebSphere Application Server adopts the open architecture paradigm and provides many plug- in points to integrate with enterprise software components. Plug-in points are based on standard J2EE specifications wherever applicable proxy server server System Web service csIv2 security protocol security protocol Credential ssociation WebSphere J2EE interceptor Application Server connector Security server Access manage (Authentication) (Authorization) Principal JAAS UserRegistry Security Role-based gin module interface User registry Tivoli Access Manager The dark blue shaded background indicates the boundary between the WebSphere Application Server Version 7.0 and other business application components WebSphere Application Server provides Simple WebSphere Authentication Mechanism Lightweight Third Party Authentication(LTPA), and Kerberos as the authentication mechanism. Exactly one authentication mechanism can be configured to be the active authentication mechanism for the security domain of WebSphere Application Server. Exactly one user registry implementation can be configured to be the active user registry of Web Sphere Application Server security domain. Web SphereApplication Server provides the following user registry implementations: UNIX Windows, and i5/OS local OS and Lightweight Directory Access Protocol(LDAP). It also provides file-based and Java database connectivity (JDBC)-based user registry reference implementations. It supports a flexible combination of authentication mechanisms and user registries. SWAM is simple to configure and is useful for a single application server environment. LTPA generates a security token for authenticated users. It is possible to use SWAM in a distributed environment if identity assertion is enabled. The identity assertion feature is available only on the CSlv2 security protocol Note: SWAM was deprecated in Web Sphere Application Server Version 7.0 and will be removed in a future release The LTPA authentication mechanism is designed for distributed security Downstream servers can validate the security token. It also supports setting up a trust association relationship with reverse secure proxy 10 Administering applications and their environm
The standard security models and interfaces that support secure socket communication, message encryption, and data encryption are the Java Secure Socket Extension (JSSE) and the Java Cryptographic Extension (JCE). Open architecture paradigm An application server plays an integral part in the multiple-tier enterprise computing framework. IBM WebSphere Application Server adopts the open architecture paradigm and provides many plug-in points to integrate with enterprise software components. Plug-in points are based on standard J2EE specifications wherever applicable. WebSphere Application Server Access manager (Authorization) Principal/ credential mapping J2EE connector Trust association interceptor CSIv2 security protocol Application server Enterprise Information System Secure reverse proxy server JAAS login module User registry Credential mapping Security server (Authentication) UserRegistry interface JAAS login module Web service security protocol JACC interface Security Role-based authorization Tivoli Access Manager JACC provider (ND) The dark blue shaded background indicates the boundary between the WebSphere Application Server Version 7.0 and other business application components. WebSphere Application Server provides Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA), and Kerberos as the authentication mechanism. Exactly one authentication mechanism can be configured to be the active authentication mechanism for the security domain of WebSphere Application Server. Exactly one user registry implementation can be configured to be the active user registry of WebSphere Application Server security domain. WebSphereApplication Server provides the following user registry implementations: UNIX®, Windows, and i5/OS® local OS and Lightweight Directory Access Protocol (LDAP). It also provides file-based and Java database connectivity (JDBC)-based user registry reference implementations. It supports a flexible combination of authentication mechanisms and user registries. SWAM is simple to configure and is useful for a single application server environment. LTPA generates a security token for authenticated users. It is possible to use SWAM in a distributed environment if identity assertion is enabled. The identity assertion feature is available only on the CSIv2 security protocol. Note: SWAM was deprecated in WebSphere Application Server Version 7.0 and will be removed in a future release. The LTPA authentication mechanism is designed for distributed security. Downstream servers can validate the security token. It also supports setting up a trust association relationship with reverse secure proxy 10 Administering applications and their environment
servers and single sign-on (SSO), which is discussed later. Besides the combination of LTPA and LDAP ol Custom user registry interface, Version 6. x or higher supports LTPA with a LocalOS user registry interface WebSphere Application Server supports the J2EE Connector architecture and offers container-managed authentication. It provides a default Java 2 Connector (J2C) principal and credential mapping module that to the Java 2 Connector and JAAS specifications. Other mapping login modules can be plugged h o e maps any authenticated user credential to a password credential for the specified Enterprise Information Systems(EIS) security domain. The mapping module is a special JAAS login module designed according Web services security WebSphere Application Server enables you to secure Web services based upon the Organization for th Advancement of Structured Information Standards(OASIS) Web services security Version 1.1 specification. These standards address how to provide protection for messages exchanged in a Web service environment. The specification defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the Trust associations Trust association enables you to integrate IBM Web Sphere Application Server security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the Web Sphere Application Server applies its own authorization policy onto the resulting credentials that are passed by the proxy server. The reverse proxy server applies its authentication policies to every Web request that is dispatched to Web Sphere Application Server. The products that implement trust association interceptors(TAl)include IBM Tivoli Access Manager for e-business WebsEAL Caching Proxy For more information on using trust association refer to Trust associations Security attribute propagation Security attribute propagation enables Web Sphere Application Server to transport security attributes from one server to another in your configuration. Security attributes include authenticated subject contents and security context information. WebSphere Application Server can obtain these security attributes from An enterprise user registry that queries static attributes A custom login module that can query static or dynamic attributes Security attribute propagation provides propagation services using Java serialization for any objects that are contained in the subject. For more information on using security attribute propagation, refer to Security attribute propagation Single sign- on interoperability mode In WebSphere Application Server, the interoperability mode option enables Single Sign-on(SsO) connections between WebSphere Application Server version 5. 1.1 or later to interoperate with previous versions of the application server. When you select this option, WebSphere Application Server adds the old-style Ltpa Token into the response so that it can be sent to other servers that work only with this token type. This option applies only when the Web inbound security attribute propagation option is enabled. For more information on single sign-on, refer to Implementing single sign-on to minimize Web user Chapter 1 Overview and new features: Administering 11
servers and single sign-on (SSO), which is discussed later. Besides the combination of LTPA and LDAP or Custom user registry interface, Version 6.x or higher supports LTPA with a LocalOS user registry interface. WebSphere Application Server supports the J2EE Connector architecture and offers container-managed authentication. It provides a default Java 2 Connector (J2C) principal and credential mapping module that maps any authenticated user credential to a password credential for the specified Enterprise Information Systems (EIS) security domain. The mapping module is a special JAAS login module designed according to the Java 2 Connector and JAAS specifications. Other mapping login modules can be plugged in. Web services security WebSphere Application Server enables you to secure Web services based upon the Organization for the Advancement of Structured Information Standards (OASIS) Web services security Version 1.1 specification. These standards address how to provide protection for messages exchanged in a Web service environment. The specification defines the core facilities for protecting the integrity and confidentiality of a message and provides mechanisms for associating security-related claims with the message. Trust associations Trust association enables you to integrate IBM WebSphere Application Server security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the WebSphere Application Server applies its own authorization policy onto the resulting credentials that are passed by the proxy server. The reverse proxy server applies its authentication policies to every Web request that is dispatched to WebSphere Application Server. The products that implement trust association interceptors (TAI) include: v IBM Tivoli Access Manager for e-business v WebSEAL v Caching Proxy For more information on using trust association, refer to Trust associations. Security attribute propagation Security attribute propagation enables WebSphere Application Server to transport security attributes from one server to another in your configuration. Security attributes include authenticated subject contents and security context information. WebSphere Application Server can obtain these security attributes from either: v An enterprise user registry that queries static attributes v A custom login module that can query static or dynamic attributes Security attribute propagation provides propagation services using Java serialization for any objects that are contained in the subject. For more information on using security attribute propagation, refer to Security attribute propagation. Single sign-on interoperability mode In WebSphere Application Server, the interoperability mode option enables Single Sign-on (SSO) connections between WebSphere Application Server version 5.1.1 or later to interoperate with previous versions of the application server. When you select this option, WebSphere Application Server adds the old-style LtpaToken into the response so that it can be sent to other servers that work only with this token type. This option applies only when the Web inbound security attribute propagation option is enabled. For more information on single sign-on, refer to Implementing single sign-on to minimize Web user authentications Chapter 1. Overview and new features: Administering 11
Security for J2EE resources using Web containers and EJB containers Each container provides two kinds of security: declarative security and programmatic security. In declarative security, the security structure of an application, including data integrity and confidentiality, authentication requirements, security roles, and access control, is expressed in a form external to the application. In particular the deployment descriptor is the primary vehicle for declarative security in the J2EE platform Web Sphere Application Server maintains a J2EE security policy, including information derived from the deployment descriptor and specified by deployers and administrators in a set of XML descriptor files. At run time, the container uses the security policy defined in the XML descriptor files to enforce data constraints and access control. When declarative security alone is not sufficient to express the security model of an application, the application code can use programmatic security to make access decisions. The application programming interface(API) for programmatic security consists of two methods of the Enterprise JavaBeans(EJB)EJBContext interface(isCallerInRole, getCallerPrincipal)and three methods of the servlet Http Servletrequest interface(isuserinrole, getuser prIncipal, getremoteuSer) Java 2 security WebSphere Application Server supports the Java 2 security model. All the system codes in the yellow box, including the administrative subsystem, the Web container, and the EJB container code, are running in the ebSphere Application Server security domain, which in the present implementation are granted with AllPermission and can access all system resources Application code running in the application security domain, which by default is granted with permissions according to J2EE specifications, can access only a restricted set of system resources. Web Sphere Application Server run-time classes are protected by the WebSphere Application Server class loader and are kept invisible to application code Java 2 Platform, Enterprise Edition Connector security WebSphere Application Server supports the J2EE Connector architecture and offers container-managed authentication. It provides a default J2C principal and credential mapping module that maps any authenticated user credential to a password credential for the specified Enterprise Information Systems (EIS)security domain All of the application server processes, by default, share a common security configuration, which is defined in a cell-level security XML document. The security configuration determines whether WebSphere Application Server security is enforced, whether Java 2 security is enforced, the authentication mechanism and user registry configuration, security protocol configurations, JAAS login configurations, and Secure Sockets Layer configurations. Applications can have their own unique security requirements. Each application server process can create a per server security configuration to address its own security requirement. Not all security configurations can be modified at the application server level. Some security be enforced, whether Java 2 security should be enforced, and security protocol configurations ity should configurations that can be modified at application server level include whether application secur The administrative subsystem security configuration is always determined by the cell level security document. The Web container and EJB container security configuration are determined by the optional per server level security document, which has precedence over the cell-level security document. Security configuration, both at the cell level and at the application server level, are managed either by the Web-based administrative console application or by the appropriate scripting application Web security hen a security policy is specified for a Web resource and IBM WebSphere Application Server security is enforced, the Web container performs access control when the resource is requested by a Web client. The Web container challenges the Web client for authentication data if none is present according to the 12 Administering applications and their environm
Security for J2EE resources using Web containers and EJB containers Each container provides two kinds of security: declarative security and programmatic security. In declarative security, the security structure of an application, including data integrity and confidentiality, authentication requirements, security roles, and access control, is expressed in a form external to the application. In particular the deployment descriptor is the primary vehicle for declarative security in the J2EE platform. WebSphere Application Server maintains a J2EE security policy, including information derived from the deployment descriptor and specified by deployers and administrators in a set of XML descriptor files. At run time, the container uses the security policy defined in the XML descriptor files to enforce data constraints and access control. When declarative security alone is not sufficient to express the security model of an application, the application code can use programmatic security to make access decisions. The application programming interface (API) for programmatic security consists of two methods of the Enterprise JavaBeans (EJB) EJBContext interface (isCallerInRole, getCallerPrincipal) and three methods of the servlet HttpServletrequest interface (isUserInRole, getUserPrincipal, getRemoteUser). Java 2 security WebSphere Application Server supports the Java 2 security model. All the system codes in the yellow box, including the administrative subsystem, the Web container, and the EJB container code, are running in the WebSphere Application Server security domain, which in the present implementation are granted with AllPermission and can access all system resources. Application code running in the application security domain, which by default is granted with permissions according to J2EE specifications, can access only a restricted set of system resources. WebSphere Application Server run-time classes are protected by the WebSphere Application Server class loader and are kept invisible to application code. Java 2 Platform, Enterprise Edition Connector security WebSphere Application Server supports the J2EE Connector architecture and offers container-managed authentication. It provides a default J2C principal and credential mapping module that maps any authenticated user credential to a password credential for the specified Enterprise Information Systems (EIS) security domain. All of the application server processes, by default, share a common security configuration, which is defined in a cell-level security XML document. The security configuration determines whether WebSphere Application Server security is enforced, whether Java 2 security is enforced, the authentication mechanism and user registry configuration, security protocol configurations, JAAS login configurations, and Secure Sockets Layer configurations. Applications can have their own unique security requirements. Each application server process can create a per server security configuration to address its own security requirement. Not all security configurations can be modified at the application server level. Some security configurations that can be modified at application server level include whether application security should be enforced, whether Java 2 security should be enforced, and security protocol configurations. The administrative subsystem security configuration is always determined by the cell level security document. The Web container and EJB container security configuration are determined by the optional per server level security document, which has precedence over the cell-level security document. Security configuration, both at the cell level and at the application server level, are managed either by the Web-based administrative console application or by the appropriate scripting application. Web security When a security policy is specified for a Web resource and IBM WebSphere Application Server security is enforced, the Web container performs access control when the resource is requested by a Web client. The Web container challenges the Web client for authentication data if none is present according to the 12 Administering applications and their environment
specified authentication method, ensures that the data constraints are met, and determines whether the authenticated user has the required security role. WebSphere Application Server supports the following login methods Http basic authentication Https client authentication Form-based Login Mapping a client certificate to a Web Sphere Application Server security credential uses the UserRegistry implementation to perform the mapping On WebSphere Application Server Express, the local OS user registry does not support the mapping function When the LTPA authentication mechanism is configured and single sign-on(SSo)is enabled, an authenticated client is issued a security cookie, which can represent the user within the specified security domain It is recommended that you use Secure Sockets Layer(SSL)to protect the security cookie or Basic Authentication information from being intercepted and replayed. When a trust association is configured WebSphere Application Server can map an authenticated user identity to security credentials based on the trust relationship established with the secure reverse proxy server. Web Security Http clien Trust Certificate Authenticated Authenticated user principal HIPS Clien Credential certificate mapping role-based JSP files, and User ID and password access cont Http basic HTML files authentication Form-based login HttpSsEcUrity Validation When considering Web security collaborators and EJB security collaborators 1. The Web security collaborator enforces role-based access control by using an access manager implementation. An access manager makes authorization decisions based on the security policy derived from the deployment descriptor. An authenticated user principal can access the requested Servlet or JSP file if the user principal has one of the required security roles. Servlets and JSP files can use the htTp servletreQuest methods isuserInrole, getuserpriNcipal, and getremoteuSer. As an Chapter 1. Overview and new features: Administering 13
specified authentication method, ensures that the data constraints are met, and determines whether the authenticated user has the required security role. WebSphere Application Server supports the following login methods: v HTTP basic authentication v HTTPS client authentication v Form-based Login Mapping a client certificate to a WebSphere Application Server security credential uses the UserRegistry implementation to perform the mapping. On WebSphere Application Server Express, the local OS user registry does not support the mapping function. When the LTPA authentication mechanism is configured and single sign-on (SSO) is enabled, an authenticated client is issued a security cookie, which can represent the user within the specified security domain. It is recommended that you use Secure Sockets Layer (SSL) to protect the security cookie or Basic Authentication information from being intercepted and replayed. When a trust association is configured, WebSphere Application Server can map an authenticated user identity to security credentials based on the trust relationship established with the secure reverse proxy server. Reverse secure proxy server Trust association interceptor HTTPs HTTP X.509 Certificate User ID and password User identity Authenticated user principal Authenticated user principal Client certificate HTTP basic authentication Form-based login Security cookie Security role-based access control Web resources: servlets, JSP files, and HTML files HTTP client Security token HTTPs Web Security Authentication Validation Credential mapping When considering Web security collaborators and EJB security collaborators: 1. The Web security collaborator enforces role-based access control by using an access manager implementation. An access manager makes authorization decisions based on the security policy derived from the deployment descriptor. An authenticated user principal can access the requested Servlet or JSP file if the user principal has one of the required security roles. Servlets and JSP files can use the HttpServletRequest methods: isUserInRole, getUserPrincipal, and getRemoteUser. As an Chapter 1. Overview and new features: Administering 13