next up previous
Next: An Extended Example Up: Representation and Evaluation of Previous: GAA API Security Context

Creation of the 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 up previous
Next: An Extended Example Up: Representation and Evaluation of Previous: GAA API Security Context
Tatyana Ryutov 2002-06-25