Using a custom role service  Supporting external single sign-on providers

Chapter 10: Creating and Using Custom Security Components

Using a custom authorization service

You can create and install your own component to authorize clients to access resources (packages, Web applications, or applications) on any EAServer.

Deciding whether to use the authorization services and role service

Using an authorization service offers greater control than using a role service, but the API is more complicated than the role service API.

The role service acts server-wide, and evaluates user membership in declared EAServer roles associated with a resource (package, component, method, or Web resource collection).

An authorization service can control access to all resources on a server, or only those in a particular application, Web application, or package. With the authorization service, you can allow or deny access to resources with no dependencies on roles configured in EAServer.

You can use both a role service and an authorization service. For example, you may wish to use a role service to preserve the ability to configure role-based resource permissions in EAServer Manager, but use the authentication service to create audit logs of user access to resources.

Creating the authorization service

An authorization service component must implement the CtsSecurity::AuthorizationService IDL interface, and be stateless to support refresh. It must be one of:


                    interface AuthorizationService {
                         boolean isAuthorized( 
                                 in CtsSecurity::SessionInfo sessionInfo, 
                                 in StringSeq resource,
                                 in StringSeq roles,
                                 in boolean isMember, 
                                  in long permTimeDelta);

isAuthorized checks if the client is authorized to access a resource. The client’s credentials can be obtained from sessionInfo.

resource is the entity the client is trying to access. The resource is represented as an ordered array of strings, and each string represents a scoped entity. A string starts with one of these prefixes:

For example, if the resource being accessed is a servlet or a JSP that belongs to a Web application, which belongs to an application, then the array might contain the following string sequence:

A:ApplicationName; WA:WebApplicationName; S:servletName; HM:httpMethod; 

roles lists all the roles associated with the resource (if any). The server first checks if the role is defined in the repository. If the role is defined, then membership checks are performed and if the user is in at least one of the roles, the authorization check succeeds. isAuthorized is still invoked, and the caller can audit the resource access. isMember is set to AUTH_OK to indicate that the authorization succeeded. If a role is not defined, it is assumed that the user is not a member of the role.

If the user is not a member of all the roles, then isMember is set to AUTH_FAILED. isAuthorized then determines whether to authorize the client. isAuthorized returns true if the user is allowed access to the resource, and returns false otherwise.

permTimeDelta is the time difference in seconds, since the last time isAuthorized was invoked for this particular user and resource combination. This value can be used by the authorization component logic to determine whether to audit the event. A value of zero (0) implies that the isMember was not determined from the internal permission cache. A positive value indicates that the isMember was determined from the internal permission cache. permTimeDelta is always less than or equal to the server-wide authorization permission cache timeout value (see the property).

For more information, see the generated documentation for the CtsSecurity::AuthorizationService IDL interface.

Installing the authorization service

Use EAServer Manager to install the authorization service component in the server, application, package, or Web application. There are two ways in which you can make the authorization service available to all components on EAServer:

Component URLs for the authorization service

There are two accepted forms of the URL:

Copyright © 2005. Sybase Inc. All rights reserved. Supporting external single sign-on providers