![]() ![]() ![]() ![]() ![]() ![]() |
The following section describes enabling security settings for Web Services and for OAM MBeans.
One of the first things you must do in setting up your Network Gatekeeper installation is to make decisions about two key forms of security for your installation: Web Services security and MBean security. Web Services security controls Network Gatekeeper’s interactions with Application Service Providers. MBean security controls who can have access to the Runtime MBean Server within your WLS installation, the mechanism that allows OAM procedures to be done.
Web Services security provides end-to-end message-level security for web services through an implementation of the WS-Security standard.
WS-Security defines a mechanism for adding three levels of security to SOAP messages:
Note: | Out of the box, Network Gatekeeper is pre-configured to use user name/password authentication. |
Network Gatekeeper uses a WebLogic Server mechanism for Web Services Security -WSSE policies:
Authentication is handled transparently by WS-Security and subsequently by the configured authentication providers and login modules of the WebLogic Security framework. WS-Security also supports signing and encrypting a message by providing a security token hierarchy associated with the keys used for signing and encryption (for message integrity and confidentiality).
The following steps outline the general WebLogic security configurations that can be performed, either automatically using a script or manually from the Administration Console.
This section outlines how to apply an existing WS-Policy and where to find more information on creating and using custom WS-Policies.
This section outlines how to apply a WSSE policy to a Web Service endpoint in Network Gatekeeper.
Note: | By default, Network Gatekeeper is pre-configured to use the WS-Security with UsernameToken. It is also set up to require this authentication only for inbound traffic. The following description is provided in case this particular mechanism does not cover the needs of your installation. |
Standard WebLogic Server mechanisms are used - see http://download.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/webservices/ConfigureWSPolicyFile.html for a full desccription.
This shows the page Settings for <Web Service>
<beahome>/domains/<wlng-domain>/./servers/WLNG_AT1/stage/wlng_at/plan/Plan.xml
(For a single instance development machine, substitute your server name for WLNG_AT1) Note: | Applying a security policy to a Web Service establishes, by default, both inbound and outbound security policies. Because there is no way for Network Gatekeeper to know what security policies may be required by a client to which it is returning a notification, outbound security must be turned off. If you wish to secure the link by which Network Gatekeeper returns notifications, you should use SSL. |
Note: | To turn off outbound security associated with a particular WS-Policy file, you must edit the plan.xml file that is created when you attach Policy to a Web Service, as in step 8 above. The default location is: /domains/<wlng-access-network-domain>/servers/WLNG_AT1/stage/wlng_at/plan/Plan.xml , but your location may vary. Make sure the <value> element is set to inbound as in the following stanza: |
<variable>
<name>WsPolicy_policy:Auth.xml_Direction_11745107731400</name>
<value>inbound</value>
</variable>
This section outlines how to setting up WSSE with X.509.
This section outlines how to apply a WSSE policy of the type UsernameToken with Digest to a Web Service endpoint in Network Gatekeeper.
Starting in the Administrative Console:
WEB-INF/policies
directory of the WAR file for the Web Service. Repackage it and redeploy it.
Use the WS-Policy file WsPolicy:UsernameTokenDigestPolicy.xml
Edit the deployment plan, plan.xml
, to indicate inbound only for entry WsPolicy_policy: UsernameTokenDigestPolicy.xml
in plan.xml
<?xml version="1.0"?>
<!-- WS-SecurityPolicy -->
<wsp:Policy
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wssp="http://www.bea.com/wls90/security/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wls="http://www.bea.com/wls90/security/policy/wsee#part"
>
<!-- Identity Assertion -->
<wssp:Identity>
<wssp:SupportedTokens>
<!-- Use UsernameToken for authentication -->
<wssp:SecurityToken IncludeInMessage="true"
TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken">
<wssp:UsePassword
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest"/>
</wssp:SecurityToken>
</wssp:SupportedTokens>
</wssp:Identity>
</wsp:Policy>
Network Gatekeeper 2.2 and earlier used a different mode of authentication than the WS-Security model. Network Gatekeeper can be configured to support applications designed to work using the older model, but the WS-Policy that is configured out of the box must be removed.
Note: | The easiest way to do this is to make these changes before you start Network Gatekeeper up the first time. Certain configuration values are cached on start up. So, for example, if you started Network Gatekeeper during the Post-Install phase in order to set up additional JMS Servers, you will need to redeploy the wlng_at.ear file after you have made your changes. |
To remove the policy files from a Web Service:
weblogic-webservices-policy.xml
file for that Web Service to remove the policy entries.Note: | See Listing 13-3 and Listing 13-4 for before and after snippets. |
<?xml version='1.0' encoding='UTF-8'?>
<webservice-policy-ref xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<port-policy>
<port-name>AudioCall</port-name>
<ws-policy>
<uri>policy:Auth.xml</uri>
<direction>inbound</direction>
</ws-policy>
</port-policy>
</webservice-policy-ref>
<?xml version='1.0' encoding='UTF-8'?>
<webservice-policy-ref xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></webservice-policy-ref>
weblogic-webservices-policy.xml
fileEAR
file.Section Creating and Using a Custom WS-Policy File in http://download.oracle.com/docs/cd/E13222_01/wls/docs100/webserv_sec/message.html describes how to create and use a custom WS-Policy file. Also see http://download.oracle.com/docs/cd/E13222_01/wls/docs100/ConsoleHelp/taskhelp/webservices/ConfigureWSPolicyFile.html.
WS-Policy files can be used to require applications clients to authenticate, digitally encrypt, or digitally sign SOAP messages. Out-of-the-box Network Gatekeeper supplies files to do those three things, respectively: auth.xml, encrypt.xml, and sign.xml. If the built-in WS-Policy files do not meet your security needs, you can build custom policies.
See http://download.oracle.com/docs/cd/E13222_01/wls/docs100/webserv_sec/message.html for a description.
WS-Policy assertions are used to specify a Web Services’ requirements for digital signatures and encryption, along with the security algorithms and authentication mechanisms that it requires, for example Policy for SAML.
Access to the OAM functionality of WebLogic Network Gatekeeper- both through the Console and through external mechanisms - is made using Java Management Extension (JMX) MBeans. Access to these MBeans is controlled by JMX Policy, which associates administrative user groups with access privilege levels. When Network Gatekeeper is installed, there are no controls established by default on access to the OAM MBeans. Each installation must make decisions about access based on its own needs.
Administrative users and groups are set up as described in Managing Management Users and Management User Groups. To control how these users have access to MBeans, and thus OAM functionality, you must assign JMX Policy to these user groups. You use the WLS Console to do this, as described in Create JMX Policies. Each policy can do the following:
For example, to give a user complete access to an MBean, select WLNG_Administrator’s Group in the policy condition.
In addition to controlling access to OAM functionality in a general way - ReadOnly, ReadWrite, etc. - you may also wish to control access by Service group. So, for example, if you have users whose job is limited to setting up and managing Application Service Providers through a system using the Partner Relationship Management interfaces, you might want to give them, and only them, ReadWrite privileges, but only to a subset of the available MBeans, those having to do with the operator part of those transactions. To do this you have to create custom XACML policies to attach to these subsets. Network Gatekeeper uses the standard WebLogic Server mechanisms for doing this.See Securing WebLogic Resources Using Roles and Policies, particularly the chapters “Using XACML Documents to Secure WebLogic Resources” and “Reference for XACML on WebLogic Server” for a detailed description of the process. For the basic process you must:
![]() ![]() ![]() |