跳过导航链接 | |
退出打印视图 | |
Oracle Solaris 11 开发者安全性指南 Oracle Solaris 11 Information Library (简体中文) |
在 API 的实现之间 GSS-API 的某些方面可能有所不同。 大多数情况下,实现之间的差异对程序只有很小的影响。 在所有情况下,开发者都可以不依赖任何特定于给定实现(包括 Oracle Solaris 实现)的操作来最大化可移植性。
Oracle Solaris 实现中没有定制的 GSS-API 函数。
GSS-API 实现在与名称对应的可列显语法中可能有所不同。 对于可移植性,应用程序不应该比较使用人工可读(即可列显)格式的名称。 相反,这些应用程序应该使用 gss_compare_name() 来确定内部格式名称是否与任何其他名称匹配。
Oracle Solaris gss_display_name() 实现按以下方式显示名称。 如果 input_name 参数表示用户主体,则 gss_display_name() 将返回 user_principal@realm 作为 output_name_buffer,返回 gss_OID 值作为 output_name_type。 如果 Kerberos v5 是基础机制,则 gss_OID 为 1.2.840.11354.1.2.2。
如果 gss_display_name() 接收到的名称是 gss_import_name() 使用 GSS_C_NO_OID 名称类型创建的,则 gss_display_name() 将在 output_name_type 参数中返回 GSS_C_NO_OID。
gss_display_name() 函数将输出字符串 "<anonymous>",以指示匿名 GSS-API 主体。 与此名称关联的名称类型 OID 为 GSS_C_NT_ANONYMOUS。 Oracle Solaris 实现支持的其他有效可列显名称不应以尖括号 (<>) 括起。
以下数据类型已作为指针实现,但某些实现可能将这些类型指定为算术类型:gss_cred_t、gss_ctx_id_t 和 gss_name_t。
如果上下文建立失败,则 Oracle Solaris 实现不会自动删除部分生成的上下文。 因此,应用程序应该通过使用 gss_delete_sec_context() 删除上下文来处理此事件。
Oracle Solaris 实现将通过内存管理自动释放存储的数据(如内部名称)。 但是,当不再需要数据元素时,应用程序仍然应该调用相应的函数(如 gss_release_name())。
对通道绑定的支持随机制而变化。 Diffie-Hellman 机制与 Kerberos v5 机制都支持通道绑定。
开发者应该假设通道绑定数据没有保密性保护。 尽管 Kerberos v5 机制提供此保护,但通道绑定数据的保密性对于 Diffie-Hellman 机制不可用。
Oracle Solaris 实现检测并拒绝相同上下文的多次尝试导入。
Oracle Solaris 的 GSS-API 实现支持通过 gss_acquire_cred() 获取 GSS_C_INITIATE、GSS_C_ACCEPT 和 GSS_C_BOTH 凭证。
Oracle Solaris 的 GSS-API 实现支持凭证到期。 因此,程序员可以在函数(如 gss_acquire_cred() 和 gss_add_cred())中使用与凭证生命周期相关的参数。
Oracle Solaris 的 GSS-API 实现支持上下文到期。 因此,程序员可以在函数(如 gss_init_sec_context() 和 gss_inquire_context())中使用与上下文生命周期相关的参数。
Oracle Solaris 的 GSS-API 实现(与任何基础机制相反)不对 gss_wrap() 处理的消息强加最大大小。 应用程序可以使用 gss_wrap_size_limit() 确定最大消息大小。
调用 gss_wrap_size_limit() 时,Oracle Solaris 的 GSS-API 实现可以检测无效 QOP 值。
在 Oracle Solaris 的 GSS-API 实现中,函数在 minor_status 参数中仅返回特定于机制的信息。 其他实现可能在返回的次状态码中包括特定于实现的返回值。