|
|
When you create a Web Services SSM instance, the SSM is accessible via HTTP. This is appropriate for development and for debugging purposes, but production environments should use one-way SSL or two-way SSL (SSL with client authentication).
This section describes how to enable one-way SSL communication between a Web Services SSM and its client. It is assumed that the reader has basic knowledge of the SSL protocol, Certificate Authorities (CA), X.509 certificates and Java Key Stores (JKS).
In this section, %SSM_INST_HOME% represents the installation folder of the Web Services SSM, for example, c:\bea\ales30-ssm\webservice-ssm\instance\wsssm.
With one-way SSL, the SSM sends its identity certificate to the client, therefore the client must trust the CA that signed the identity certificate. (The client does not have to have its own certificate, because it is not authenticated by the Web Services SSM.)
To configure a Web Services SSM to use one-way SSL:
The client's trusted JKS is defined by the system property javax.net.ssl.trustStore and the JKS password is defined by the system property javax.net.ssl.trustStorePassword property. (These properties are defined in the Java Secure Socket Extension (JSSE) documentation.) You can specify these system properties by running the Web Services SSM Java client with command line arguments such as:
-Djavax.net.ssl.trustStore=C:\jks\trust.jks
-Djavax.net.ssl.trustStorePassword="secretword"
For testing purposes, the client can use the %SSM_INST_HOME%\ssl\trust.jks JKS, which contains the CA that was used to sign the default server's identity.
To add support for new assertion types to the Web Services SSM:
com.bea.security.ssmws.credentials namespace. In this procedure, we use a class named com.bea.security.ssmws.credentials.TestCredHolderImpl and a custom identity assertion type named TestIA. See Figure 6-1 for an example. WLESws.wrapper.conf configuration file located in BEA_HOME/ales30-ssm/webservice-ssm/instance-name/config. For example, if the holder class is contained in a file named ssmwsCustomAssertion.jar, add a line like this to WLESws.wrapper.conf:
wrapper.java.classpath.40=C:/bea/ales30-ssm/webservice-ssm/lib/ssmwsCustomAssertion.jar
| Note: | The wrapper.java.classpath lines must increment sequentially. |
castor.xml file in the BEA_HOME/ales30-ssm/webservice-ssm/lib/com/bea/security/ssmws/soap directory. Add an entry like the following inside the <mapping> XML element: <class name="com.bea.security.ssmws.credentials.TestCredHolderImpl"><map-to cst:xml="TestIA" /><field name="cookie" type="java.lang.String" ><bind-xml node="text"/></field></class>
castor.xml file in the BEA_HOME/ales30-ssm/webservice-ssm/lib/com/bea/security/ssmws/credentials directory. Add an entry like the following inside the <mapping> XML element <class name="com.bea.security.ssmws.credentials.TestCredHolderImpl"><map-to cst:xml="TestIA"cst:ns-uri="http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd" /><field name="cookie" type="java.lang.String" ><bind-xml node="text"/></field></class>
config/log4j.properties file:When the Web Services SSM is started, it will use the new holder implementation and the mapping entries to convert back and forth between the token's XML and Java representations.
public class TestCredHolderImpl implements CredentialHolder
{
private String m_cookie;
public static final String m_Type = "TestIA";
public void setCookie(String cookie)
{
m_cookie = cookie;
}
public String getCookie()
{
return m_cookie;
}
public Object getObject()
{
return getCookie();
}
public void setObject(Object cred)
{
setCookie((String)cred);
}
public String getType()
{
return TestCredentialHolderImpl.m_Type;
}
public String getAsString()
{
return m_cookie;
}
}
|