...

If you need integrations with other application servers, please ask us and we can provide it for you.

When to

...

Use an Agent, and

...

When Not to Do So

Often, it is desirable to minimize the impact of Ceptor implementation in an organization, and in some cases the organizational cost (tickets, education, operations, configuration) of having an Agent installed in hundreds of application servers is not desirable.

...

• JEE Subject integration - provides user and group principals in Java Subject available to the application server and applications running inside.
• IIS / .NET integration.
• Authorization - integrates with standard JEE containers, enables support for container-based authorization checking using deploymentdescriptor, annotations etc.
• Complex Authorization (e.g. with WebLogic, authorization SSPI plugins enables attribute based authorizationenablesattribute basedauthorization).
• Fine-grained authorization.
• APIs for logging users in or out, checking access, creating tokens etc. - see Ceptor Agent for details about the API functionality.
• Logging framework (slf4j, log4j, logback) integration - client applications log can be sent to Ceptor Server.
• Distributed session, with cached attributes.

...

• No JEE Subject / .NET authorization integration is needed.
• Only read-only access to data, such as social security number, name or groups is needed - these attributes can then be picked out and added to the headers by the gateway in front.
• No need to logon or logoff users.
• No fine-graded authorization checking is needed, or the application will do authorization itself based upon some other source of information.

Also note that even without having an Agent installed within an application, it can always make a remote call to one if an application needs to e.g. log a user in or out - a remote webservice/rest call will then be needed instead.