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:

• Java CORBA

• PowerBuilder Non-Visual User Object (NVO)

• C++ CORBA

• Component Object Model (COM)

Usage

                    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:

• A: – application

• WA: – Web application

• P: – package

• C: – component

• M: – method

• S: – servlet

• HM: – HTTP method (GET, PUT, POST, and so on)

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 com.sybase.jaguar.server.authorization.permcachetimeout 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:

• Allow multiple packages, Web applications, or applications to share the same authorization service by setting the same value for the authorization service component. If the application utilizes a particular authorization service, then all components accessed by the application also utilize the same authorization service. To configure an authorization service:

  • At the package level, set the com.sybase.jaguar.package.authorization.service property to the URL for the component that implements this interface in the Advanced tab of the Package Properties window.

  • At the Web application level, set the com.sybase.jaguar.webapplication.authorization.service property to the URL for the component that implements this interface in the Advanced tab of the Web Applications Properties window.

  • At the application level, set the com.sybase.jaguar.application.authorization.service property to the URL for the component that implements this interface in the Advanced tab of the Applications Properties window.

• Enable the interface on the entire server. Set the com.sybase.jaguar.server.authorization.service property to the URL for the component that implements this interface in the Advanced tab of the Server Properties window. Packages, Web applications, and applications can utilize the authorization service.

Component URLs for the authorization service

There are two accepted forms of the URL:

• For all component types, the URL can be set to the EAServerPackage/EAServerComponent; the component must be installed in the server.

  For example, to set the authorization service at the server level, set the server-level property to:

  com.sybase.jaguar.server.authorization.service=Security/Authorizer

  Where Security is the name of the Jaguar package that contains an EAServer component called Authorizer that implements this interface.

• Java CORBA and C++ CORBA components can be accessed using the pseudocomponent object URL. The syntax for a Java pseudocomponent is:

  pseudo://java/JavaClass/EAServerPackage/EAServerComponent
  

  The syntax for a C++ pseudocomponent is:

  pseudo://cpp/SharedLibraryName/EAServerPackage/EAServerComponent
  

  You can also set the authorization service property to the pseudocomponent object URL. For example, set the server-level authorization service to:

  pseudo://cpp/libAuthorizer/Security/Authorizer 
  

  where libAuthorizer is the name of the shared library that contains the C++ Security/Authorizer component’s implementation.

  Components implemented for pseudocomponent access must be thread-safe, and you must restart EAServer to refresh the component.

  For more information on pseudocomponents, see Chapter 34, “Creating and Using EAServer Pseudocomponents,” in the EAServer Programmer’s Guide.

Copyright © 2005. Sybase Inc. All rights reserved.