Programming Guides › Programming Guide for Java › Agent API Guidance for C › User Access to Resources

User Access to Resources

The agent must perform the following steps before granting a user access to a requested resource. The outcome of most steps can be cached to improve agent performance. The agent can choose to cache as little or as much as possible.

1. Accept a user request.

   Accept a user request to access a resource. This is the application-specific request. For example, the Web Agent would accept a user’s GET request for a URL.

2. Check if the resource is protected.

   Call isProtected() to determine if the requested resource is protected.

   If the resource is protected, the policy server returns the required credentials that must be obtained from the user in order to validate the user’s identity. If the resource is not protected, access to the requested resource should be allowed.

   The outcome of this step can be cached.

3. Authenticate the user.

   Call login() to collect the required credentials from the user and to authenticate the user.

   Upon successful authentication, the Policy Server creates a session and returns response attributes, including the unique session id and session specification. These response attributes are policy-driven and may include user profile data, static or dynamic privileges, a number of predefined authentication state attributes, or any other data that was designated by a policy administrator.

   The agent can now perform session management by caching user session information and keeping track of session expiration.

4. Check if the user is authorized.

   Call authorize() to validate that the user has access to the requested resource.

   Upon successful authorization, the policy server returns response attributes including resource-specific privileges. These response attributes are policy driven and may include user profile data, static or dynamic privileges, or any other data that was designated by a policy administrator.

   At this point the user’s authorization information with respect to the requested resource is known and can be cached to speed up future requests.

5. Audit cached authorization information.

   Both the authentication and authorization steps log the relevant information about the user, the protected resource, and the agent. However, if the agent performs authorizations out of its cache, the transaction can still be logged through the audit() method.

6. Allow access to resource.

   Now that the user’s identity is known, authorization has been verified, and the required entitlements obtained, give the authorized user access to the resource.

7. Issue a management request.

   This is an optional step that is used to poll the Policy Server for update commands. In response to a command, agents update encryption keys or flush caches or both.

When the agent is no longer needed, issue the unInit() method for each API instance. This closes TCP connections to all policy servers.

Note: The Agent API does not provide a facility for caching in a manner that enforces session validity. By choosing to cache user sessions and/or resource-specific privileges, the agent becomes obligated to perform its own session management during each user request. This is required, since caching on the agent removes the need to contact the SiteMinder Policy Server to perform session validation and/or resource authorizations.