Retrieving remote attributes using GSS-API naming extensions
draft-perez-abfab-gss-remote-attr-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Alejandro Pérez-Méndez , Rafael Marin-Lopez , Gabriel Lopez-Millan | ||
| Last updated | 2016-04-07 (Latest revision 2015-10-05) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The GSS-API Naming Extensions define new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. Historically, this set of functions has been used to obtain the authorization information contained in some sort of authorization token provided to the GSS acceptor during the context establishment process, such as a Kerberos ticket, a SAML assertion, or an X.509 attribute certificate. However, some scenarios require to allow the GSS acceptor to request additional attributes after context establishment. If these attributes are not locally stored by the GSS mechanism they have to be retrieved from an external source (e.g. SQL database, LDAP directory, external IdP, etc.). This document describes how current GSS-API extensions are able to encompass such functionality without requiring of any change, neither on the existing calls nor on the way applications use the API.
Authors
Alejandro Pérez-Méndez
Rafael Marin-Lopez
Gabriel Lopez-Millan
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)