InfoCenter Home >
5: Securing applications -- special topics >
5.7: The Secure Association Service (SAS) >
5.7.2: SAS on the server side

5.7.2: SAS on the server side

When an RMI/IIOP request arrives at a server, SAS intercepts the request and performs the necessary security tasks before the business method is invoked on the server. After the method is invoked, a response is sent back to the client.

Configuring the Server

Configuring a server for security starts at the administrative console in the Security Center. The properties specified there are propagated into the WebSphere Application Server repository and then eventually to the sas.server.props file for use by the SAS runtime. Some of the properties in the sas.server.props file are from the Security Center configuration and some are defaults which are editable in the file. The sas.server.props file documents which properties can be changed without getting overwritten and which will get overwritten by the information in the repository. See 5.7.5: SAS properties reference for more info about these properties.

Authenticating the user

When a server first receives a request, a user must be authenticated and authorized before the method can be invoked. Part of SAS's responsibility is to authenticate the user to the user registry to validate that they are who they say. The SAS programming model has APIs for authenticating users on both the client and server sides. Currently, the only client authentication supported is Basic Auth (i.e., authenticating a userid and password). SSL client authentication is planned for a future release.

Invoking the method

Once SAS authenticates the user, a credential is created with information about the user. This credential is associated with the thread of execution and the method is invoked in the container after being authorized.

Sending a response back to the client

After the method is invoked, a response is sent back to the client.

Credential forwarding - support for multiple nodes

Local OS credentials are only supported on the same node they were created. Therefore, when using the Local OS registry, only a single node configuration is supported. If you need a multi-node configuration, LTPA is the only supported option as the credentials can be validated with trust on another node (that is, a different physical machine).

Credential expiration for LTPA credentials

When using the LTPA authentication mechanism, authenticated credentials have a configurable expiration period. When users make a request to a server, a credential is created on the server side and associated with the user's SAS security session on the server side. After the initial user request is made to a server, the SAS security session is stateful (meaning it will remember the state of the user). Every subsequent user request will use the same SAS security session and the same user credentials. Make sure that you set a high enough value for the LTPA credential expiration time to keep user credentials from expiring after a series of requests.

Go to previous article: Client-side SAS Go to next article: ORB SSL Configuration

 

 
Go to previous article: Client-side SAS Go to next article: ORB SSL Configuration