Security migration

Creating a secret key

In WebSphere sMash 1.0, you used the user zone for persisting security state related to SimpleToken and Cross Site Request Forgery (CSRF) tokens. To eliminate this dependency on the user, security now requires generation of a secret key when configuring security for the application. For more information about generating a secret key, see the Secret key encryption section of the Developer's Guide.

Defining security rules using rule.config

WebSphere sMash 1.0 defined a way to define security constraints using the rule.config template, as shown in the following example.

@include "security/rule.config"{
   "conditions": "(/request/path =~ /customers(/.*)?)  && (/request/method =~ (PUT|POST)) ",
   "authType" : "Basic",
   "users" : ["myUser1"],
   "groups" : ["CUSTOMERS"]
}

Defining custom authentication handlers using authType

In WebSphere sMash 1.0, you implemented a custom authentication handler using the following steps:

1. Choose a name for your authentication scheme to be specified in the security rules as authType.
2. Implement a handler for the event name <authType>Secure.
3. Register the event name in the configuration file of your library or application as a handler for that event.

For example, if your authType is digest, you would implement a handler with the method onDigestSecure and add the following stanza to the configuration file:

/config/handlers += [{
   "events" : "digestSecure",
   "handler" : "com.myimpl.DigestSecurityHandler.class"
}]

Defining custom security token handlers using tokenType

In WebSphere sMash 1.0, you created a custom token implementation using the following methods:

<tokenType>Attach

Creates a new token

<tokenType>Validate

Validates a token

<tokenType>Logout

Handles a user logout

The details of the <tokenType> token are described in the following section. You can register the handler in your library, or in the zero.config file of the application, as a handler for those events. For example, if your tokenType is customToken, you would implement a handler with the following methods:

onCustomTokenAttach

Creates a new CustomToken token

onCustomTokenValidate

Validates a CustomToken token

onCustomTokenLogout

Handles logout processing

The following example shows the settings for configuring a custom token named CustomToken in the application or library zero.config file:

/config/security/token/tokenType="customToken"
/config/handlers += [{
        "events" : ["customTokenAttach", "customTokenValidate", 
                       "customTokenLogout"],
        "handler" : "custom.CustomTokenService.class"
}]

Using configuration template requirelocalhost

In WebSphere sMash 1.0, you restricted requests to applications to just a localhost client named requirelocalhost.config as shown in the following example.

# Security for Management REST APIs
@include "security/requirelocalhost.config"{
   "conditions" : "/request/path =~ /opsmanager(/.*)?",
   "requireLocalhost": true
}

@include "security/requirelocalhost.config"{
   "conditions" : "/request/path =~ /configmanager(/.*)?",
   "requireLocalhost": true
}