This chapter describes the necessary steps for securing an application using a remote SSM.
When OES security calls using the Java API have been implemented in a custom application, SSM proxy services can be set up on the application host and used to communicate with a remote SSM on another machine. The SSM proxy provides local security services, including caching, logging, and failover support.
RMI or SOAP can be used as the transport mechanism for communication between the SSM proxy and the remote SSM. (In XACML terminology, the SSM proxy and remote SSM are be analogous to PDP Proxy and PDP respectively.)
Note: | For this release, there is no separate install for the RMI SSM. It is available only by installing and instantiating a Web Services SSM. |
To create a Web Service instance, see Configuring SSMs Using ConfigTool.
To set up the SSM proxy on the client application:
Web Service SSM— BEA_HOME\ales32-ssm\webservice-ssm\<instance>\pdpproxy
RMI SSM— BEA_HOME\ales32-ssm\webservice-ssm\<instance>\rmi-ssm\pdpproxy
BEA_HOME\ales32-shared\keys
to the same directory on the application client containing the Jar files.Note: | The demonstration trust keystore provided during installation is named DemoTrust.jks . This can be used in development and testing environments. |
To specify the SSM proxy location, use a system property in the command line, such as: -Dpdp.configuiration.properties.location=D:\pdpproxy\PDPClientConfiguration.properties
.
PDPProxyConfiguration.properties
in a text editor and set the values as described in Table 7-1.
A comma-separated list of the url of the primary remote SSM and port number and one or more failover SSMs.
|
|
How caching, logging, and failover are configured depends on the whether it is the remote SSM or the SSM proxy.
Caching configuration on the remote SSM is determined by settings established on the authorization provider being used by the SSM. This is managed using the Administration Console.
The SSM proxy uses the same caching configuration established on the remote SSM. In addition, the SynchronizationIntervalMilliSecs setting in PDPProxyConfiguration.properties
determines how often to poll the remote SSM to see if re-synchronization is necessary.
The cache on the SSM proxy cannot be flushed from the Administration Console. However, the SSM proxy cache is automatically flushed when whenever there is a new policy distribution on the SSM (subject to the SynchronizationIntervalMilliSecs parameter). In addition, if this is not sufficient, the ability to flush the cache may be added to the application client using the following methods of the AuthorizationService class:
These methods can be invoked from either the SSM or the SSM proxy. They will simultaneously flush both the client and server cache.
Logging configuration on the remote SSM is determined by settings established on the auditing provider being used by the SSM. This is managed using the Administration Console.
On the SSM proxy, logging can be implemented using the Apache Log4j package (log4j.jar) that is included in the pdpproxy
directory that was copied from the SSM instance.
Failover support for an SSM proxy can be implemented by deploying one or more failover SSMs and then pointing to those SSMs using the PDPAddress setting in PDPProxyConfiguration.properties
. The first specified SSM will be the primary SSM; the second will be the failover SSM.
To add support for new identity 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 7-1 for an example. WLESws.wrapper.conf
configuration file located in BEA_HOME/ales32-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/ales32-ssm/webservice-ssm/lib/ssmwsCustomAssertion.jar
Note: | The wrapper.java.classpath lines must increment sequentially. |
castor.xml
file in the BEA_HOME/ales32-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/ales32-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;
}
}