Next: An Extended Example
Up: Representation and Evaluation of
Previous: GAA API Security Context
Prior to calling the gaa_check_authorization function,
the application must obtain the authenticated principal's identity
and store it in the security context. This context may be
constructed from credentials obtained from different mechanisms, e.g. GSS
API, Kerberos or others.
This scenario places a heavy burden on the application programmer
to provide the integration of the security mechanism with the
application. A second scenario is to obtain the authentication
credentials from a transport protocol that already has the
security context integrated with it. For example, the application can call
SSL or authenticated RPC.
In this case, it is the implementation of the transport mechanism
(usually written by someone other than the application programmer) which calls
the security API requesting principal's identity.
The principal's authentication information is placed into the
security context and passed to the GAA API. When additional security
attributes are required for the requested operation, the list of
required attributes is returned to the application, which may request them.
The application may provide the GAA API with an upcall function for
requesting required additional credentials.
The credentials pulled by the GAA API are verified and added to
the security context by the upcall function. A reference to the
upcall function is passed to the GAA API as part of the security
context, and is added to the security context by the application or
transport.
Next: An Extended Example
Up: Representation and Evaluation of
Previous: GAA API Security Context
Tatyana Ryutov
2002-06-25