Table of Contents
Users who run clients can programmatically set up the authorization scheme to enforce on a per invocation basis. The properties and configuration information required depends on the configured authorization scheme. Section 5, “Semantics and syntax of domain-specific interface” describes the configuration steps in more detail.
Using self authorization: Ensure that the client is running with the same credentials as the effective server-side credential (resource, service, container credential, in the order of occurrence).
Using host authorization:
Ensure that the effective server-side credential (resource, service, container credential, in the order of occurrence) is the host credential of the machine on which the service is running.
Ensure that the client is not using 127.0.0.1 as the host address to access the service, but the actual host name.
Using identity authorization: Ensure that the DN matches the server's DN exactly. If using the command line interface quotes might have to be placed around the DN string for spaces to be maintained.
When using GSI Secure Conversation delegation of credentials cannot be done if no authorization of the server is done (that is, if client side authorization is set to none). Use any other form of authorization while delegating.
Alternatively, Delegation Service can be used to delegate credentials in scenarios where delegated credentials are required but no authorization of the server is required.
![[Important]](../../../../../docbook-images/important.gif) | Important |
|---|---|
Delegating credentials without authorizing server is not recommended since a malicious server can obtain the client's credential. |