Weblogic security
0 likes398 views
WebLogic Security provides a comprehensive security architecture for securing WebLogic Server applications. It includes features such as authentication, authorization, auditing, identity assertion, and supports standards like SAML, JAAS, and WS-Security. The security service can be used standalone or as part of an enterprise security solution. It aims to balance ease of use with customizability and provides both default and customizable security providers.
Weblogic security
- 2. Overview of Weblogic Security • ··Introduction to the WebLogic Security Service • ··Features of the WebLogic Security Service • ··Oracle Platform Security Services (OPSS) • ··Balancing Ease of Use and Customizability • ··New and Changed Features in This Release
- 3. Introduction to the WebLogic Security Service ● Deploying, managing, and maintaining security is a huge challenge for an information technology (IT) organization that is providing new and expanded services to customers using the Web. To serve a worldwide network of Web-based users, an IT organization must address the fundamental issues of maintaining the confidentiality, integrity and availability of the system and its data. Challenges to security involve every component of the system, from the network itself to the individual client machines. Security across the infrastructure is a complex business that requires vigilance as well as established and well-communicated security policies and procedures. ● WebLogic Server includes a security architecture that provides a unique and secure foundation for applications that are available via the Web. By taking advantage of the security features in WebLogic Server, enterprises benefit from a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the Web. WebLogic security can be used standalone to secure WebLogic Server applications or as part of an enterprise-wide, security management system that represents a best-in-breed, security management solution.
- 4. Features of the WebLogic Security Service ● A comprehensive and standards-based design. ● End-to-end security for WebLogic Server-hosted applications, from the mainframe to the Web browser. ● Legacy security schemes that integrate with WebLogic Server security, allowing companies to leverage existing investments. ● Security tools that are integrated into a flexible, unified system to ease security management across the enterprise. ● Easy customization of application security to business requirements through mapping of company business rules to security policies. ● A consistent model for applying security policies to Java EE and application-defined resources. ● Easy updates to security policies. This release includes usability enhancements to the process of creating security policies as well as additional expressions that control access to WebLogic resources. ● Easy adaptability for customized security solutions.
- 5. Features of the WebLogic Security Service ● A modularized architecture, so that security infrastructures can change over time to meet the requirements of a particular company. ● Support for configuring multiple security providers, as part of a transition scheme or upgrade path. ● A separation between security details and application infrastructure, making security easier to deploy, manage, maintain, and modify as requirements change. ● Default WebLogic security providers that provide you with a working security scheme out of the box. This release supports additional authentication stores such as databases, and gives the option to configure an external RDBMS system as a datastore to be used by select security providers. ● Customization of security schemes using custom security providers ● Unified management of security rules, security policies, and security providers through the WebLogic Server Administration Console.
- 6. Features of the WebLogic Security Service • Support for standard Java EE security technologies such as the Java Authentication and Authorization Service (JAAS), Java Secure Sockets Extensions (JSSE), Java Cryptography Extensions (JCE), and Java Authorization Contract for Containers (JACC). • A foundation for Web services security including support for Security Assertion Markup Language (SAML) 1.1 and 2.0. • Capabilities which allow WebLogic Server to participate in single sign-on (SSO) with web sites, web applications, and desktop clients. • A framework for managing public keys which includes certificate lookup, verification, validation, and revocation as well as a certificate registry.
- 7. Oracle Platform Security Services (OPSS) ● Oracle Platform Security Services (OPSS) provides enterprise product development teams, systems integrators (SIs), and independent software vendors (ISVs) with a standards-based, portable, integrated, enterprise-grade security framework for Java Standard Edition (Java SE) and Java Enterprise Edition (Java EE) applications. ● OPSS provides an abstraction layer in the form of standards-based application programming interfaces (APIs) that insulates developers from security and identity management implementation details. With OPSS, developers don't need to know the details of cryptographic key management or interfaces with user repositories and other identity management infrastructures. With OPSS, in-house developed applications, third-party applications, and integrated applications all benefit from the same uniform security, identity management, and audit services across the enterprise. OPSS is available as part of WebLogic Server.
- 8. Balancing Ease of Use and Customizability ● Easy to use: WebLogic Server provides a Domain Configuration Wizard to help with the creation of new domains with an administration server, managed servers, and optionally, a cluster, or with extending existing domains by adding individual severs. The Domain Configuration Wizard also automatically generates a config.xml file and start scripts for the servers you choose to add to the new domain. ● Manageable: Administrators who configure and deploy applications in the WebLogic Server environment can use the WebLogic security providers included with the product. These default providers support all required security functions, out of the box. An administrator can store security data in the WebLogic Server- supplied, security store (an embedded, special-purpose, LDAP directory server) or use an external LDAP server, database, or user source. To simplify the configuration and management of security in WebLogic Server, a robust, default security configuration is provided. ● Customizable: For application developers, WebLogic Server supports the WebLogic security API and Java EE security standards such as JAAS, JSS, JCE, and JACC. Using these APIs and standards, you can create a fine-grained and customized security environment for applications that connect to WebLogic Server.
- 9. Security Fundamentals • ··Auditing • ··Authentication • ··Security Assertion Markup Language (SAML) • ··Single Sign-On (SSO) • ··Authorization • ··Identity and Trust • ··Secure Sockets Layer (SSL) • ··Firewalls
- 10. Auditing ● Auditing is the process whereby information about operating requests and the outcome of those requests are collected, stored, and distributed for the purposes of non-repudiation. In other words, auditing provides an electronic trail of computer activity. In the WebLogic Server security architecture, an Auditing provider is used to provide auditing services. ● If configured, the WebLogic Security Framework will call through to an Auditing provider before and after security operations (such as authentication or authorization) have been performed, when changes to the domain configuration are made, or when management operations on any resources in the domain are invoked. The decision to audit a particular event is made by the Auditing provider itself and can be based on specific audit criteria and/or severity levels. The records containing the audit information may be written to output repositories such as an LDAP server, database, and a simple file.
- 11. Authentication Authentication is the mechanism by which callers prove that they are acting on behalf of specific users or systems. Authentication answers the question, "Who are you?" using credentials such as username/password combinations. In WebLogic Server, Authentication providers are used to prove the identity of users or system processes. Authentication providers also remember, transport, and make identity information available to various components of a system (via subjects) when needed. During the authentication process, a Principal Validation provider provides additional security protections for the principals (users and groups) contained within the subject by signing and verifying the authenticity of those principals.
- 12. Authentication – Subjects and Principals Subjects and principals are closely related. A principal is an identity assigned to a user or group as a result of authentication. Both users and groups can be used as principals by application servers such as WebLogic Server. The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals. As part of a successful authentication, principals are signed and stored in a subject for future use. A Principal Validation provider signs principals, and an Authentication provider's LoginModule actually stores the principals in the subject. Later, when a caller attempts to access a principal stored within a subject, a Principal Validation provider verifies that the principal has not been altered since it was signed, and the principal is returned to the caller (assuming all other security conditions are met). Any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces, which are available in
- 13. Authentication – Java Authentication and Authorization Service (JAAS) Whether the client is an application, applet, Enterprise JavaBean (EJB), or servlet that requires authentication, WebLogic Server uses the Java Authentication and Authorization Service (JAAS) classes to reliably and securely authenticate to the client. JAAS implements a Java version of the Pluggable Authentication Module (PAM) framework, which permits applications to remain independent from underlying authentication technologies. Therefore, the PAM framework allows the use of new or updated authentication technologies without requiring modifications to your application. WebLogic Server uses JAAS for remote fat-client authentication, and internally for authentication. Therefore, only developers of custom Authentication providers and developers of remote fat client applications need to be involved with JAAS directly. Users of thin clients or developers of within-container fat client applications (for example, those calling an Enterprise JavaBean (EJB) from a servlet) do not require the direct use or knowledge of JAAS.
- 14. Authentication – CallbackHandlers ● A CallbackHandler is a highly-flexible JAAS standard that allows a variable number of arguments to be passed as complex objects to a method. There are three types of CallbackHandlers: NameCallback, PasswordCallback, and TextInputCallback, all of which are part of the javax.security.auth.callback package. The NameCallback and PasswordCallback return the username and password, respectively. TextInputCallback can be used to access the data users enter into any additional fields on a login form (that is, fields other than those for obtaining the username and password). When used, there should be one TextInputCallback per additional form field, and the prompt string of each TextInputCallback must match the field name in the form. WebLogic Server only uses the TextInputCallback for form-based Web application login. ● An application implements a CallbackHandler and passes it to underlying security services so that they may interact with the application to retrieve specific authentication data, such as usernames and passwords, or to display certain information, such as error and warning messages. ● CallbackHandlers are implemented in an application-dependent fashion. For example, implementations for an application with a graphical user interface (GUI) may pop up windows to prompt for requested information or to display error messages. An implementation may also choose to obtain requested information from an alternate source without asking the user. ● Underlying security services make requests for different types of information by passing individual Callbacks to the CallbackHandler. The CallbackHandler implementation decides how to retrieve and display information depending on the Callbacks passed to it. For example, if the underlying service needs a username and password to authenticate a user, it uses a NameCallback and PasswordCallback. The CallbackHandler can then choose to prompt for a username and
- 15. Authentication – Mutual Authentication With mutual authentication, both the client and the server are required to authenticate themselves to each other. This can be done by means of certificates or other forms of proof material. WebLogic Server supports two-way SSL authentication, which is a form of mutual authentication. However, by strict definition, mutual authentication takes place at higher layers in the protocol stack then does SSL authentication.
- 16. Authentication – Servlet Authentication Filters As defined by the Java Servlet API 2.3 specification, filters are objects that can modify a request or response. Filters are preprocessors of the request before it reaches the servlet, and/or postprocessors of the response leaving the servlet. Filters provide the ability to encapsulate recurring tasks in reusable units. Filters can be used as a substitute for container-based authentication but there are some drawbacks to this design: • As specified by the Java Servlet API 2.3 specification, filters are run after authentication and authorization. If filters are used for authentication, they must also be used for authorization thereby preventing container-managed authorization from being used. Most use cases that require extensions to the authentication process in the Servlet container do not require extensions to the authorization process. Having to implement the authorization process in a filter is awkward, time consuming, and error-prone. • J2EE filters are defined per Web application. Code for a filter must reside in the WAR file for the Web application and the configuration must be defined in the web.xml file. An authentication mechanism is typically determined by the system administrator after an application is written (not by the programmer who created the WAR file). The mechanism can be changed during the lifetime of an application, and is desired for all (or at least most) applications in a site.
- 17. Authentication – Identity Assertion Providers and LoginModules When used with a LoginModule, Identity Assertion providers support single sign-on. For example, an Identity Assertion provider can process a SAML assertion so that users are not asked to sign on more than once. The LoginModule that an Identity Assertion provider uses can be: • Part of a custom Authentication provider you develop. • Part of the WebLogic Authentication provider that Oracle developed and packaged with WebLogic Server. • Part of a third-party security vendor's Authentication provider. Unlike in a simple authentication situation, the LoginModules that Identity Assertion providers use do not verify proof material such as usernames and passwords; they simply verify that the user exists.
- 18. Authentication – Identity Assertion and Tokens Identity Assertion providers support user name mappers, which map a valid token to a WebLogic Server user. You develop Identity Assertion providers to support the specific types of tokens that you will be using to assert the identities of users or system processes. You can develop an Identity Assertion provider to support multiple token types, but the WebLogic Server administrator must configure the Identity Assertion provider so that it validates only one "active" token type. While you can have multiple Identity Assertion providers in a security realm with the ability to validate the same token type, only one Identity Assertion provider can actually perform this validation.
- 19. Authentication – Challenge Identity Assertion Challenge identity assertion schemes provide for multiple challenges, responses messages, and state. A WebLogic Server security realm can include security providers that support authentication protocols such as Microsoft's Windows NT Challenge/Response (NTLM), Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), and other challenge/response authentication mechanisms. WebLogic Server includes a SPNEGO security provider, named the Negotiate Identity Assertion provider. You can develop and deploy security providers that implement NTLM or other challenge/response authentication mechanisms.
- 20. Authentication – Servlet Authentication Filters As defined by the Java Servlet API 2.3 specification, filters are objects that can modify a request or response. Filters are preprocessors of the request before it reaches the servlet, and/or postprocessors of the response leaving the servlet. Filters provide the ability to encapsulate recurring tasks in reusable units. Filters can be used as a substitute for container-based authentication but there are some drawbacks to this design: • As specified by the Java Servlet API 2.3 specification, filters are run after authentication and authorization. If filters are used for authentication, they must also be used for authorization thereby preventing container-managed authorization from being used. Most use cases that require extensions to the authentication process in the Servlet container do not require extensions to the authorization process. Having to implement the authorization process in a filter is awkward, time consuming, and error-prone. • J2EE filters are defined per Web application. Code for a filter must reside in the WAR file for the Web application and the configuration must be defined in the web.xml file. An authentication mechanism is typically determined by the system administrator after an application is written (not by the programmer who created the WAR file). The mechanism can be changed during the lifetime of an application, and is
- 21. SAML Security Assertion Markup Language (SAML) The SAML standard defines a common XML framework for creating, requesting, and exchanging security assertions between software entities on the Web. This framework specifies how SAML assertions and protocols may be used to provide the following: • Browser-based single sign-on (SSO) between online business partners • The exchange of identity information in web services security
- 22. SAML Security Assertion Markup Language (SAML) SAML was developed by the Organization for the Advancement of Structured Information Standards (OASIS), and this release of WebLogic Server includes broad support for SAML 1.1 and 2.0, including support for the following: • SAML Web SSO profile The SAML Web SSO profile specifies how SAML assertions and protocols should be used to provide browser-based single sign-on between an Identity Provider (a producer of assertions) and a Service Provider (a consumer of assertions). In the SAML 2.0 Web SSO profile, a web user either invokes a resource hosted by a Service Provider site, or accesses an Identity Provider site in a way that results in an invocation on a resource hosted by the Service Provider. In either case, the web user is authenticated by the Identity Provider, which in turn generates an assertion on behalf of that user that contains information about the user's identity. The Identity Provider sends the assertion to the Service Provider, which consumes the assertion by extracting identity information about the user that is mapped to a Subject in the local security realm.
- 23. SAML Security Assertion Markup Language (SAML) • Web Services Security (WS-Security) SAML Token profile 1.1 The SAML Token profile is part of the core set of WS-Security standards, and specifies how SAML assertions can be used for Web services security. WebLogic Server supports SAML Token Profile 1.1, including support for SAML 2.0 and SAML 1.1 assertions. SAML Token Profile 1.1 is backwards compatible with SAML Token Profile 1.0.
- 24. Single Siggn On (SSO) Single Sign-On is the ability to require a user to sign on to an application only once and gain access to many different application components, even though these components may have their own authentication schemes. Single sign-on enables users to login securely to all their applications, web sites and mainframe sessions with just one identity. WebLogic Server provides single sign-on (SSO) with the following environments: • ··Web Browsers and HTTP Clients via SAML • ··Desktop Clients
- 25. Authorization Authorization is the process whereby the interactions between users and WebLogic resources are controlled, based on user identity or other information. In other words, authorization answers the question, "What can you access?" In WebLogic Server, an Authorization provider is used to limit the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability. The following sections describe authorization concepts and functionality: • ··WebLogic Resources • ··Security Policies • ··ContextHandlers • ··Access Decisions • ··Adjudication • ··Java Authorization Contract for Containers (JACC)
- 26. Identity and Trust Private keys, digital certificates, and trusted certificate authority certificates establish and verify identity and trust in the WebLogic Server environment. The public key is embedded into a digital certificate. A private key and digital certificate provide identity. The trusted certificate authority (CA) certificate establishes trust for a certificate. Certificates and certificate chains need to be validated before a trust relationship is established. This topic details the concepts associated with identity and trust. For more information, see: • ··Private Keys • ··Digital Certificates • ··Certificate Authorities • ··Certificate Lookup and Validation
- 27. Secure Sockets Layer(SSL) WebLogic Server fully supports SSL communication, which enables secure communication between applications connected through the Web. This release of WebLogic Server includes support for using the Java Secure Socket Extension (JSSE) as the SSL stack for the following: • Incoming SSL connections. • Outgoing SSL connections that use the WebLogic SSL APIs (it has always been possible for applications to call JSSE directly for outbound SSL connections).
- 28. Firewall A firewall limits traffic between two networks. Firewalls can be a combination of software and hardware, including routers and dedicated gateway machines. They employ filters that allow or disallow traffic to pass based on the protocol, the service requested, routing information, and the origin and destination hosts or networks. They may also allow access for authenticated users. You can use the following features in WebLogic Server in conjunction with firewalls: • ··Connection Filters • ··Perimeter Authentication
- 29. Java EE and Weblogic Security For implementation and use of user authentication and authorization, WebLogic Server utilizes the security services of the JDK version 6.0. Like the other Java EE components, the security services are based on standardized, modular components. WebLogic Server implements these Java security service methods according to the standard, and adds extensions that handle many details of application behavior automatically, without requiring additional programming. WebLogic Server's support for Java EE 6.0 security means that application developers can take advantage of Sun Microsystems' latest enhancements and developments in the area of security, thus leveraging a company's investment in Java programming expertise. By following the defined and documented Java standard, WebLogic Server's security support has a common baseline for Java developers. The innovations that WebLogic Server provides rest on the baseline support for J2SE 5.0. The following topics are discussed in this section: • ··Java EE 6.0 Security Packages • ··Common Secure Interoperability Version 2 (CSIv2)