gss_accept_sec_context - accept a security context initiated by a peer application
cc [ flag... ] file... -lgss [ library... ] #include <gssapi/gssapi.h> OM_uint32 gss_accept_sec_context(OM_uint32 *minor_status, gss_ctx_id_t *context_handle, const gss_cred_id_t acceptor_cred_handle, const gss_buffer_t input_token, const gss_channel_bindings_t input_chan_bindings, const gss_name_t * src_name, gss_OID * mech_type, gss_buffer_t output_token, OM_uint32 *ret_flags, OM_uint32 * time_rec, gss_cred_id_t *delegated_cred_handle);
The parameter descriptions for gss_accept_sec_context() follow:
minor_status
context_handle
acceptor_cred_handle
input_token_buffer
input_chan_bindings
src_name
mech_type
output_token
ret_flags
GSS_C_DELEG_FLAG
GSS_C_MUTUAL_FLAG
GSS_C_REPLAY_FLAG
GSS_C_SEQUENCE_FLAG
GSS_C_CONF_FLAG
GSS_C_INTEG_FLAG
GSS_C_ANON_FLAG
GSS_C_PROT_READY_FLAG
GSS_C_TRANS_FLAG
time_rec
delegated_cred_handle
The gss_accept_sec_context() function allows a remotely initiated security context between the application and a remote peer to be established. The routine may return an output_token, which should be transferred to the peer application, where the peer application will present it to gss_init_sec_context(). See gss_init_sec_context(3GSS). If no token need be sent, gss_accept_sec_context() will indicate this by setting the length field of the output_token argument to zero. To complete the context establishment, one or more reply tokens may be required from the peer application; if so, gss_accept_sec_context() will return a status flag of GSS_S_CONTINUE_NEEDED, in which case it should be called again when the reply token is received from the peer application, passing the token to gss_accept_sec_context() by means of the input_token parameters.
Portable applications should be constructed to use the token length and return status to determine whether to send or to wait for a token.
Whenever gss_accept_sec_context() returns a major status that includes the value GSS_S_CONTINUE_NEEDED, the context is not fully established, and the following restrictions apply to the output parameters:
The values of the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG, GSS_C_REPLAY_FLAG, GSS_C_SEQUENCE_FLAG, GSS_C_CONF_FLAG, GSS_C_INTEG_FLAG and GSS_C_ANON_FLAG bits returned by means of the ret_flags parameter are values that would be valid if context establishment were to succeed.
The values of the GSS_C_PROT_READY_FLAG and GSS_C_TRANS_FLAG bits within ret_flags indicate the actual state at the time gss_accept_sec_context() returns, whether or not the context is fully established. However, applications should not rely on this behavior, as GSS_C_PROT_READY_FLAG was not defined in Version 1 of the GSS-API. Instead, applications should be prepared to use per-message services after a successful context establishment, based upon the GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG values.
All other bits within the ret_flags argument are set to zero.
While gss_accept_sec_context() returns GSS_S_CONTINUE_NEEDED, the values returned by means of the the ret_flags argument indicate the services available from the established context. If the initial call of gss_accept_sec_context() fails, no context object is created, and the value of the context_handle parameter is set to GSS_C_NO_CONTEXT. In the event of a failure on a subsequent call, the security context and the context_handle parameter are left untouched for the application to delete using gss_delete_sec_context(3GSS). During context establishment, the informational status bits GSS_S_OLD_TOKEN and GSS_S_DUPLICATE_TOKEN indicate fatal errors; GSS-API mechanisms always return them in association with a routine error of GSS_S_FAILURE. This pairing requirement did not exist in version 1 of the GSS-API specification, so applications that wish to run over version 1 implementations must special-case these codes.
gss_accept_sec_context() may return the following status codes:
GSS_S_COMPLETE
GSS_S_CONTINUE_NEEDED
GSS_S_DEFECTIVE_TOKEN
GSS_S_DEFECTIVE_CREDENTIAL
GSS_S_NO_CRED
GSS_S_CREDENTIALS_EXPIRED
GSS_S_BAD_BINDINGS
GSS_S_NO_CONTEXT
GSS_S_BAD_SIG
GSS_S_OLD_TOKEN
GSS_S_DUPLICATE_TOKEN
GSS_S_BAD_MECH
GSS_S_FAILURE
Example 1 Invoking gss_accept_sec_context() Within a Loop
A typical portable caller should always invoke gss_accept_sec_context() within a loop:
gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT; do { receive_token_from_peer(input_token); maj_stat = gss_accept_sec_context(&min_stat, &context_hdl, cred_hdl, input_token, input_bindings, &client_name, &mech_type, output_token, &ret_flags, &time_rec, &deleg_cred); if (GSS_ERROR(maj_stat)) { report_error(maj_stat, min_stat); }; if (output_token->length != 0) { send_token_to_peer(output_token); gss_release_buffer(&min_stat, output_token); }; if (GSS_ERROR(maj_stat)) { if (context_hdl != GSS_C_NO_CONTEXT) gss_delete_sec_context(&min_stat, &context_hdl, GSS_C_NO_BUFFER); break; }; } while (maj_stat & GSS_S_CONTINUE_NEEDED); /* Check client_name authorization */ ... (void) gss_release_name(&min_stat, &client_name); /* Use and/or store delegated credential */ ... (void) gss_release_cred(&min_stat, &deleg_cred);
See attributes(5) for descriptions of the following attributes:
|
gss_delete_sec_context(3GSS), gss_export_sec_context(3GSS), gss_get_mic(3GSS), gss_init_sec_context(3GSS), gss_release_cred(3GSS), gss_release_name(3GSS), gss_store_cred(3GSS), gss_wrap(3GSS), attributes(5)
Solaris Security for Developers Guide
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |