How are AquaLogic Service Bus and WebLogic Server Security related?
AquaLogic Service Bus leverages the WebLogic Security Framework. The details of this framework are described in “WebLogic Security Framework” in WebLogic Security Service Architecture in Understanding WebLogic Security. Before configuring security in AquaLogic Service Bus, you must configure a WebLogic Server security realm and other server configurations (such as SSL) in WebLogic Server, as described in Configuring the WebLogic Security Framework: Main Steps.
What is Transport-Level Security?
Transport-level security refers to the transport protocols that secure the connection over which messages are transported. An example of transport-level security is HTTPS (HTTP over SSL). SSL provides point-to-point security, but does not protect the message when intermediaries exist in the message path. For more information, see Configuring Transport-Level Security.
What is Web Services Security?
Web Services Security (WS-Security) is an OASIS standard that defines interoperable mechanisms to incorporate message-level security into SOAP messages. WS-Security supports message integrity and message confidentiality. It also defines an extensible model for including security tokens in a SOAP envelope and a model for referencing security tokens from within a SOAP envelope. WS-Security token profiles specify how specific token types are used within the core WS-Security specification. Message integrity is achieved through the use of XML digital signatures; message confidentiality is accomplished through the use of XML encryption. WS-Security allows you to specify which parts of a SOAP message are digitally signed or encrypted. AquaLogic Service Bus supports WS-Security over HTTP, HTTPS, and JMS. For more information on WS-Security see Web Services Security: SOAP Message Security 1.0 (WS-Security 2004) at the following URL:
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
What is Web Service Policy?
The Web Services Policy Framework (WS-Policy) provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web service specifications to describe a broad range of service requirements, preferences, and capabilities. For more information, see Using Web Services Policy to Specify Inbound Message-Level Security.
What are Web Service Policy assertions?
The Web Services Policy Assertions Language (WS-PolicyAssertions) specifies a set of common message policy assertions that can be specified within a security policy. The specification defines general messaging-related assertions for use with WS-Policy. Separate specifications describe the syntax and semantics of domain-specific assertions for security assertions and reliable-messaging assertions.
Are Access Control Policy and Web Service Policy the same?
No. Access control policy is a boolean expression that is evaluated to determine which requests to access a particular resource (such as a proxy service, Web application, or EJB) are granted and which should be denied access. Typically access control policies are based on the roles of the requestor. WS-Policy is metadata about a Web service that complements the service definition (WSDL). WS-Policy can be used to express a requirement that all service clients must satisfy, such as, all requests must be digitally signed by the client.
What is Web Services Security Pass-Through?
In a WS-Security pass-through scenario, the client applies WS-Security to the request and/or response messages. The proxy service does not process the security header, instead, it passes the secured request message untouched to a business service. Although AquaLogic Service Bus does not apply any WS-Security to the message, it can route the message based on values in the header. After the business service receives the message, it processes the security header and acts on the request. The business service must be configured with WS-Policy security statements. The secured response message is passed untouched back to the client. For example, the client encrypts and signs the message and sends it to the proxy service. The proxy service does not decrypt the message or verify the digital signature, it simply routes the message to the business service. The business service decrypts the messages and verifies the digital signature, and then processes the request. The response path is similar. This is sometimes called a passive intermediary.
What is a Web Services Security Active Intermediary?
In an active intermediary scenario, the client applies WS-Security to the request and/or response messages. The proxy service processes the security header and enforces the WS-Security policy. For example, the client encrypts and signs the message and sends it to the proxy service, the proxy decrypts the message and verifies the digital signature, then routes the message. Before the proxy service sends the response back to the client, the proxy signs and encrypts the message. The client decrypts the message and verifies the proxy’s digital signature.
What is outbound Web Services Security?
Outbound WS-Security refers to security between AquaLogic Service Bus proxy services and business services. It includes both the request and response between business applications and proxy services. For more information, see About Message-Level Security.
What is SAML?
SAML (Security Assertion Markup Language) is an OASIS standards-based extensible XML framework for exchanging authentication and authorization information, allowing single sign-on capabilities in modern network environments.
Is it possible to customize the format of the subject identity in a SAML assertion?
By default, the subject identity within an outbound SAML token is the same as the inbound username. The format of the subject identity can be customized by writing a custom SAML name mapper-provider. For more information, see Configuring a SAML Credential Mapping Provider in Securing WebLogic Server.
What is the Certificate Lookup And Validation Framework?
The Certificate Lookup and Validation (CLV) providers complete certificate paths and validate X509 certificate chains. The two types of CLV providers are:
CertPath Builder—receives a certificate, a certificate chain, or certificate reference (the end certificate in a chain or the Subject DN of a certificate) from a Web service or application code. The provider looks up and validates the certificates in the chain.
CertPath Validator—receives a certificate chain from the SSL protocol, a Web service, or application code and performs extra validation, such as revocation checking.
At least one CertPath Builder and one CertPath Validator must be configured in a security realm. Multiple CertPath Validators can be configured in a security realm. If multiple providers are configured, a certificate or certificate chain must pass validation with all the CertPath Validators for the certificate or certificate chain to be valid. WebLogic Server provides the functionality of the CLV providers in the WebLogic CertPath provider and the Certificate Registry. For more information see “The Certificate Lookup and Validation Process” in WebLogic Security Service Architecture in Understanding WebLogic Security.
Does AquaLogic Service Bus support identity propagation in a proxy service?
Yes, AquaLogic Service Bus supports two methods for propagating identities:
This is done by setting a SAML holder-of-key or sender-vouches WS-Policy on the business service routed to by the proxy.
If a business service requires user name and password tokens, you can configure the business service’s service account to pass through the user credentials from the original client request. See Service Accounts in Using the AquaLogic Service Bus Console.
If both transport-level authentication and message-level authentication exist on inbound messages to the proxy service, which identity is propagated?
If both transport authentication and message-level authentication exist, the message-level subject identity is propagated.
Is single sign-on supported in AquaLogic Service Bus?
Strictly speaking single sign-on (SSO) is not applicable to AquaLogic Service Bus messaging scenarios for several reasons. First, AquaLogic Service Bus is stateless; there is no notion of a session or conversation among multiple parties. Second, AquaLogic Service Bus clients are typically other enterprise software applications, not users behind a Web browser. Therefore, it is acceptable to require that these clients send credentials such as username and password on every request, provided that the communication is secured by means such as SSL or WS-Security. However, SSO between the AquaLogic Service Bus Console and the WebLogic Server Administration Console is supported. For more information, see “Single Sign-On” in Security Fundamentals in Understanding WebLogic Security.
Are security errors monitored?
Only WS-Security errors are monitored by the AquaLogic Service Bus monitoring framework. Transport-level security errors such as SSL handshake errors, transport-level authentication and transport-level access control are not monitored in this release. For more information, see “Service Monitoring Details” in Monitoring in theAquaLogic Service Bus Operations Guide. However, it is possible to configure an Auditor provider to audit transport-level authentication and authorization.
Can I configure security for MBeans?
AquaLogic Service Bus includes two managed beans (MBeans) that configure such runtime behavior as which types of credentials are available to abstract WS-Policy statements. By default, only users in the Admin and Deployer security roles can modify these MBeans, however you can change these defaults. See Create JMX Policies in WebLogic Server Administration Console Help.
