Coherence is a data source and its data can be secured in a way that only authorized users or applications should have access to it. Another vital requirement is simplicity of configuring security. Too many configuration options make things unnecessarily complex. Typically cache security is based on a special class scheme with a custom named cache that should be used as a cache scheme for the caches that need to be protected. Following is an implementation that simplifies it a little and streamlines the scope of various components involved. Download the attached project (jDeveloper) and use it. Step (1): Change the cache configuration Following is a sample cache configuration: <!DOCTYPE cache-config SYSTEM "cache-config.dtd"> <cache-config> <caching-scheme-mapping> <cache-mapping> <cache-name>EntitledCache</cache-name> <scheme-name>distributed-scheme</scheme-name> </cache-mapping> </caching-scheme-mapping> <caching-schemes> <distributed-scheme> <scheme-name>distributed-scheme</scheme-name> <service-name>DistributedCache</service-name> <backing-map-scheme> <local-scheme></local-scheme> </backing-map-scheme> <autostart>true</autostart> <entitled> <security-provider>MySecurityProvider</security-provider> </entitled> </distributed-scheme> </caching-schemes> </cache-config> And instead of deploying any Custom Cache all you need to do is the following:
Step (2): SecurityProvider interface public interface SecurityProvider { public boolean checkAccess (Subject subject); } Step (3): Security Provider implementation The security provider is the application's responsibility. Typical implementations are Application's group name (OS), a Cryptic string or even JAAS based LDAP authentication. Step (4): Deploy the entitler.jar Put the entitler.jar in the classpath before coherence.jar bundled in the attached ZIp under the deploy/ directory. Even though not required it is recommended to use the attached cache-config.dtd as it is updated to handle new Elements. Current Status:
|