Tipo de permiso de intercambio de token: intercambio de un token Kerberos para un UPST
Utilice el intercambio de tokens de Kerberos donde Kerberos es el proveedor de autenticación y debe intercambiar tokens de Kerberos por principales o tokens de IAM para acceder a los servicios de OCI. Intercambia tokens Kerberos para tokens de sesión de principal de usuario (UPST) de OCI en IAM.
| Término | Descripción |
|---|---|
| Kerberos |
Autenticación entre plataformas y sistema de inicio de sesión único. El protocolo Kerberos proporciona autenticación mutua entre dos entidades que dependen de un secreto compartido (claves simétricas). La autenticación de Kerberos requiere que un cliente, un servidor y una parte de confianza medien entre ellos, denominado Centro de distribución de claves (KDC). También se requiere lo siguiente:
El perfil de token de Kerberos de WS-Security permite a los socios comerciales utilizar tokens de Kerberos en arquitecturas orientadas a servicios (SOA). |
| Centro de distribución de claves (KDC) de Kerberos | Un servidor de autenticación de terceros. |
| Active Directory (AD) | Un repositorio para el servidor KDC. |
| Tabla de claves |
Un archivo que almacena la clave de cifrado real que se puede utilizar en lugar de una comprobación de contraseña para un principal específico. Los archivos keytab son útiles para casos de uso no interactivos. Consejo: la herramienta de administración del KDC se puede utilizar para crear un archivo keytab. Durante la creación de la tabla de claves, se puede especificar el tipo de cifrado. Utilice el siguiente tipo de cifrado: |
| Mecanismo de Negociación GSSAPI Simple y Protegido (SPNEGO) |
El Mecanismo de Negociación GSSAPI simple y protegido (SPNEGO) es un "pseudomecanismo" GSSAPI utilizado por el software cliente/servidor para negociar la elección de la tecnología de seguridad. Los tickets de Kerberos se ajustan como parte del token SPNEGO para que el token funcione con la capa de aplicación basada en HTTP. Formato y detalles del token SPNEGO El formato del token SPNEGO se define en RFC 4178. El token es una estructura de datos serializada que contiene los siguientes campos:
El token SPNEGO está codificado en ASN.1. A continuación, se muestra un ejemplo de un token SPNEGO:
|
| GSSAPI | Interfaz de programa de aplicación de servicios de seguridad genéricos |
| API de servicio de intercambio de token de IAM | Servicio OAuth del dominio de identidad de IAM: /oauth2/v1/token. La API acepta tanto las cabeceras de autenticación/carga útil estándar basadas en OAuth como las firmas de OCI. Para obtener información sobre cómo utilizar un cliente OAuth con un dominio de identidad para acceder a las API de REST, consulte Uso de OAuth 2 para acceder a la API de REST. |
| Configuración de confianza de propagación de identidad | Utilice configuraciones de confianza de propagación de identidad para establecer la confianza entre OCI Identity y un proveedor de identidad externo y validar el token de proveedor de identidad externo y la asignación de la identidad de usuario del proveedor de identidad externo con la identidad de usuario en IAM. Identity Propagation Trust también facilita la propagación de identidad de un proveedor de identidad externo a OCI. El diseño de punto final /IdentityPropagationTrust es genérico y funciona con cualquier proveedor en la nube. Para crear una configuración de confianza de propagación de identidad, consulte el Paso 6: Creación de una configuración de confianza de propagación de identidad. |
| Usuario de servicio | Un usuario sin privilegios de conexión interactivos. Estos usuarios de servicio se pueden otorgar a grupos y roles de servicio. Las aplicaciones pueden utilizar estos usuarios de servicio o el usuario conectado puede suplantarlos para obtener un UPST temporal. El uso de un usuario de servicio es opcional. Para obtener más información sobre el uso de usuarios de servicio, consulte Paso 5: Uso de un usuario de servicio (opcional). |
| Token de sesión de principal de usuario (UPST) | Un token generado por IAM. También conocido como token de seguridad. Representa el usuario de servicio autenticado. |
Pasos de intercambio de token de Kerberos
Utilice los siguientes pasos para intercambiar un token de Kerberos por un UPST:
- Paso 1: Crear un almacén y agregar el contenido del archivo keytab
- Paso 2: Crear la política de de IAM necesaria
- Paso 3: Crear una aplicación de dominio de identidad
- Paso 4: Generar un token SPNEGO para un principal de usuario específico
- Paso 5: Uso de un usuario de servicio (opcional)
- Paso 6: Crear una configuración de confianza de propagación de identidad
- Paso 7: Consigue OCI UPST
Paso 1: Crear un almacén y agregar el contenido del archivo keytab
Cree un almacén y agregue el contenido del archivo keytab como una cadena codificada base64. Nota: IAM no almacena el archivo keytab en su sistema de archivos.
Utilice los siguientes pasos como guía:
- Cree un almacén de claves. Consulte Creación de un Almacén.
- Lea el contenido de la tabla de claves en formato Base64.
- Vaya al almacén y almacénelo tal cual, asegúrese de comprobar Base64 como Plantilla de tipo de secreto al crear el secreto. Consulte Creación de un secreto en un almacén.
Paso 2: Crear la política de de IAM necesaria
Cree una política de IAM en el arrendamiento para permitir que un recurso de dominio de identidad acceda a Vault. Esto permite a IAM recuperar la configuración de keytab de Vault. Utilice el siguiente ejemplo como guía:
allow resource domain <domain_displayName> to read secrets from vault in compartment <compartment_ocid> where all {target.secret.id = <secret_ocid_where_the_keytab_is_present>}
Paso 3: Crear una aplicación de dominio de identidad
Crear una aplicación confidencial de dominio de identidad. Después de crear la aplicación, guarde el ID de cliente y el secreto de cliente en una ubicación segura. Consulte Adición de una aplicación confidencial.
Paso 4: Generar un token SPNEGO para un principal de usuario específico
- Utilice código Java para conectarse al servidor KDC y generar el token SPNEGO.
- Copie ese token SPNEGO para formar la solicitud de token.
Utilice el siguiente ejemplo de código Java como guía:
package com.oracle;
import com.sun.security.auth.module.Krb5LoginModule;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSException;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import org.ietf.jgss.Oid;
import javax.security.auth.Subject;
import java.io.IOException;
import java.security.Principal;
import java.security.PrivilegedAction;
import java.util.Base64;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
public class GenerateSpnegoToken {
static String servicePrincipal = "HTTP/iamtesp@WINDOWSKDCSERVER.COM";
static String userPrincipal = "HTTP/<sample-job>@WINDOWSKDCSERVER.COM";
static String userPrincipalKeyTab = "keytabs/ms/<sample-job>.keytab";
public static void main(String[] args) throws IOException {
System.setProperty("sun.security.krb5.debug", "true");
System.setProperty("sun.security.spnego.debug", "true");
System.setProperty("java.security.krb5.conf", "ms_krb5.conf");
String spnegoToken = generateSpnegoToken();
}
private static String generateSpnegoToken() {
Subject subject = getAuthenticateSubject();
return Subject.doAs(
subject,
(PrivilegedAction<String>)
() -> {
String SPNEGO_OID = "1.3.6.1.5.5.2";
String KRB5_MECHANISM_OID = "1.2.840.113554.1.2.2";
String KRB5_PRINCIPAL_NAME_OID = "1.2.840.113554.1.2.2.1";
try {
// Create GSS context for the service principal and the logged-in user
Oid krb5Mechanism = new Oid(KRB5_MECHANISM_OID);
Oid krb5PrincipalNameType = new Oid(KRB5_PRINCIPAL_NAME_OID);
Oid spnegoOid = new Oid(SPNEGO_OID);
GSSManager manager = GSSManager.getInstance();
GSSName gssServerName =
manager.createName(servicePrincipal, krb5PrincipalNameType, krb5Mechanism);
GSSContext gssContext =
manager.createContext(
gssServerName, spnegoOid, null, 240000);
gssContext.requestMutualAuth(true);
gssContext.requestCredDeleg(true);
gssContext.requestLifetime(10);
// Generate the SPNEGO token
byte[] token = new byte[0];
token = gssContext.initSecContext(token, 0, token.length);
return Base64.getEncoder().encodeToString(token);
} catch (GSSException e) {
throw new RuntimeException(e);
}
});
}
private static Subject getAuthenticateSubject() {
final Map<String, String> options = new HashMap<>();
options.put("keyTab", userPrincipalKeyTab);
options.put("principal", userPrincipal);
options.put("doNotPrompt", "true");
options.put("isInitiator", "true");
options.put("refreshKrb5Config", "true");
options.put("storeKey", "true");
options.put("useKeyTab", "true");
// Execute the login
Subject subject = new Subject();
Krb5LoginModule krb5LoginModule = new Krb5LoginModule();
krb5LoginModule.initialize(subject, null, new HashMap<String, String>(), options);
try {
krb5LoginModule.login();
krb5LoginModule.commit();
} catch (Exception e) {
throw new RuntimeException(e);
}
Set<Principal> principals = (Set<Principal>) subject.getPrincipals();
Iterator<Principal> iterator = principals.iterator();
while (iterator.hasNext()) {
System.out.println("\nprincipal : " + ((Principal) iterator.next()));
}
return subject;
}
}
Paso 5: Uso de un usuario de servicio (opcional)
Un usuario de servicio es un usuario de dominios de identidad con el atributo serviceUser definido en true.
El uso de un usuario de servicio es opcional. Si la suplantación de usuario se utilizará como parte de la configuración de confianza, se necesitan usuarios de servicio. De lo contrario, se utiliza cualquier otro usuario del dominio de identidad. Solo los administradores de dominio de identidad pueden crear, sustituir, actualizar o suprimir un usuario de servicio. Otros administradores pueden leer los usuarios de servicio y sus atributos.
Para utilizar un usuario de servicio, cree uno sin privilegios de conexión interactivos. Estos usuarios de servicio se pueden otorgar a grupos y roles de servicio. Sus aplicaciones pueden utilizar estos usuarios de servicio o el usuario conectado puede suplantarlos para obtener un token UPST temporal.
Los usuarios de servicios tienen las siguientes características:
- Debe tener un valor userName. El nombre y el apellido no son necesarios.
- Puede tener una dirección de correo electrónico (opcional).
- Puede ser miembro de grupos y roles de aplicación.
- No se pueden tener claves API.
- No se pueden utilizar puntos finales de autoservicio.
- No se pueden tener contraseñas y las políticas de contraseñas no se aplican.
Ejemplo de solicitud: creación de un usuario de servicio
A continuación, se muestra un ejemplo de una solicitud con los atributos mínimos necesarios para crear un usuario de servicio.
## POST on https://<domainURL>/admin/v1/Users
## Payload:
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
"serviceUser": true
},
"userName": "myServiceUserName"
}
Ejemplo de respuesta: creación de un usuario de servicio
A continuación, se muestra un ejemplo de una respuesta al crear un usuario de servicio.
{
"idcsCreatedBy": {
"type": "App",
"display": "idcsadmin"
},
"id": "<user_id>",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
"isFederatedUser": false,
"isGroupMembershipSyncedToUsersGroups": true,
"serviceUser": true
},
"meta": {
"created": "2023-12-07T06:52:55.380Z",
"lastModified": "2023-12-07T06:52:55.380Z",
"version": "<version>",
"resourceType": "User",
"location": "https://<domainURL>/admin/v1/Users/<user_id>"
},
"active": true,
"idcsLastModifiedBy": {
"display": "idcsadmin",
"type": "App"
},
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
"locked": {
"on": false
}
},
"ocid": "ocid1.user.region1...<ocid>",
"userName": "myServiceUserName",
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:capabilities:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User"
]
}
Paso 6: Crear una configuración de confianza de propagación de identidad
La configuración de confianza de propagación de identidad se utiliza para establecer la confianza entre OCI Identity y los proveedores de nube externos, la validación del token de proveedor de nube y la asignación de la identidad de usuario del proveedor de nube con la identidad de usuario de los dominios de identidad service.
| Atributo | ¿Obligatorio? | Descripciones y ejemplos |
|---|---|---|
| nombre | Sí |
Nombre de la confianza. |
| tipo | Sí |
El tipo de token:
|
| emisor | Sí |
Utilice Emisor para ayudar a encontrar la identificación del fideicomiso. Por ejemplo, si el token SPNEGO se genera mediante el principal de servicio, Ejemplo: |
| activo | Sí |
Si está activado, Si está desactivado, |
| oauthClients | Sí |
Lista de clientes OAuth a los que se les permite obtener tokens para un socio de confianza específico. Ejemplo:
|
| allowImpersonation (utilice serviceUser) | No |
Valor booleano. Especifica si el UPST resultante debe contener el usuario autenticado como asunto o si debe suplantar a un usuario de servicio en IAM. |
| impersonatingServiceUser |
Sí, si |
Especifica qué principal resultante va a suplantar en función del nombre de reclamación de token y las condiciones de valor. Puede:
Ejemplo:
Si se permite la suplantación, el token de seguridad de OCI (UPST) resultante tendrá la reclamación original autenticada relacionada con el usuario (
|
| tabla de claves |
Sí, si el tipo de token es |
Recupera la configuración de la tabla de claves de Vault. Importante:
|
Ejemplo de solicitud: creación de una configuración de confianza de propagación de identidad
## POST on https://<domainURL>/admin/v1/IdentityPropagationTrusts
## Payload:
{
"active": true,
"allowImpersonation": false,
"issuer": "idcs_psr_itp",
"name": "<identity_propagation_trust_name>",
"oauthClients": [
"<oauthclient-id>"
],
"keytab": {
"secretOcid": "<secret_ocid>"
},
"subjectMappingAttribute": "userName",
"subjectType": "User",
"type": "SPNEGO",
"schemas": [
"urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
]
}Ejemplo de respuesta: creación de una configuración de confianza de propagación de identidad
"response": {
"name": "<identity_propagation_trust_name>",
"type": "<token_type>",
"issuer": "idcs_psr_itp",
"accountId": "<example_account_id>",
"subjectClaimName": "cognito:username",
"subjectMappingAttribute": "username",
"subjectType": "User",
"clientClaimName": "appId",
"clientClaimValues": ["<client_claim_value>"],
"active": true,
"publicKeyEndpoint": "https://example.identityprovider.com/publickey/<publickey_value>",
"publicCertificate": "<public_certificate_value>",
"oauthClients": ["<oauthclient-id>"],
"allowImpersonation": true,
"impersonationServiceUsers": [
{
"rule": "groups co \"network-admin\"",
"value": "<user_id>"
},
{
"rule": "groups co \"tenancy-admin\"",
"value": "<user_id>"
}
],
"keytab": {
"secretOcid": "<secret_ocid>",
"secretVersion": "<secret_version>"
},
"clockSkewSeconds": 60,
"id": "<identity_propagation_trust_id>",
"meta": {
"created": "2023-11-09T23:26:53.224Z",
"lastModified": "2023-11-09T23:26:53.224Z",
"resourceType": "IdentityPropagationTrust",
"location": "http://example.hostname.com:8990/admin/v1/IdentityPropagationTrusts/<identity_propagation_trust_id>"
},
"schemas": [
"urn:ietf:params:scim:schemas:oracle:idcs:IdentityPropagationTrust"
],
"idcsCreatedBy": {
"value": "<app_id>",
"display": "admin",
"type":"App",
"$ref": "http://example.hostname.com:8990/admin/v1/Apps/<app_id>"
},
"idcsLastModifiedBy": {
"value": "<app_id>",
"display": "admin",
"type":"App",
"$ref": "http://example.hostname.com:8990/admin/v1/Apps/<app_id>"
}
}Paso 7: Consigue OCI UPST
| Parámetro de solicitud | Valor válido |
|---|---|
|
|
|
|
|
|
|
|
Flujo de trabajo de clave pública:
|
|
|
|
|
|
Si el tipo de token es:
|
|
|
Obligatorio si el tipo de token es Ejemplo:
|
Ejemplo de solicitud de token UPST: basado en firmas de OCI
A continuación, se muestra un ejemplo de solicitud de cURL basada en firmas de OCI.
## OCI Signature Based Request
curl -X POST -sS https://<domainURL>/oauth2/v1/token -i
-H 'date: Wed, 06 Dec 2023 01:17:33 GMT'
-H 'x-content-sha256: <key>'
-H 'content-type: application/x-www-form-urlencoded;charset=utf-8'
-H 'content-length: 197'
-H 'Authorization: Signature version="1",keyId="<key_id>",algorithm="rsa-sha256",headers="(request-target) date host x-content-sha256 content-type content-length",signature="a+aH0b...TLtPA=="' --data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'requested_token_type=urn:oci:token-type:oci-upst' \
--data-urlencode 'public_key=<public_key>' \
--data-urlencode 'subject_token=<subject_token>' \
--data-urlencode 'subject_token_type=spnego' \
--data-urlencode 'issuer=<Issuer stored in the Identity Trust Propagation. For example, examplead@kdcserver.com>' -k
{
"token": "<token_id>"
}
Ejemplo de solicitud de token UPST: basado en aplicación de dominio de identidad
A continuación se muestra un ejemplo de solicitud de cURL basada en aplicaciones de dominio de identidad de OCI.
## IAM Domain App Based Request. Note that client credentials can be sent as part of basic authn header or in the payload.
curl --location ' https://<domainURL>/oauth2/v1/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic <auth_code>' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'requested_token_type=urn:oci:token-type:oci-upst' \
--data-urlencode 'public_key=<public_key>' \
--data-urlencode 'subject_token=<subject_token>' \
--data-urlencode 'subject_token_type=spnego' \
--data-urlencode 'issuer=<Issuer stored in the Identity Trust Propagation. For example, examplead@kdcserver.com>' -k
{
"token": "<token_id>"
}