es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

  • es.davy.ai/
  • Programación /
  • Cómo persistir el correo electrónico, el nombre y el apellido con una política personalizada de HRD

Cómo persistir el correo electrónico, el nombre y el apellido con una política personalizada de HRD

27 Jul, 2023 Programación

Tengo una versión modificada de la política CP en https://github.com/azure-ad-b2c/samples/blob/master/policies/home-realm-discovery-modern/policy/SignInsmartHRD.xml que se ejecuta en un directorio de prueba, con nuestro directorio de AD de la empresa federado como un IdP. Cuando intento iniciar sesión en una aplicación con mi dirección de correo electrónico de AD y mi cuenta no existe en el directorio B2C, se crea utilizando UserWriteUsingAlternativeSecurityId en el paso de orquestación 8. Sin embargo, la nueva cuenta de usuario solo tiene un nombre de visualización; no tiene nombre ni apellido, y lo peor de todo, no tiene correo electrónico. ¿Cómo puedo asegurarme de que estos elementos se mantengan en ese paso? No estoy seguro de cómo “agarrarlos”.

Idealmente, me gustaría que la identidad federada se vincule automáticamente a una cuenta local existente con la misma dirección de correo electrónico, sin que el usuario deba hacer una sesión local. Todos los ejemplos que he visto sobre vinculación de cuentas involucran que el usuario inicie sesión primero con una cuenta de contraseña local o que el OID del usuario esté prellenado. Solo tengo las direcciones de correo electrónico de los nuevos usuarios.

-GBS

Tags:  

Answer

  1. Avatar for davy.ai
    davy.ai

    Para asegurarse de que el nombre, apellido y dirección de correo electrónico del usuario se guarden en el OrchestrationStep 8 del CP modificado, es necesario agregar el perfil técnico ClaimsExchange para el perfil técnico AAD-UserWriteUsingAlternativeSecurityId. Este perfil técnico ClaimsExchange debe mapear las claims de entrada a las claims de salida requeridas por el perfil técnico AAD-UserWriteUsingAlternativeSecurityId.

    Aquí tienes un ejemplo de cómo agregar el perfil técnico ClaimsExchange:

    <claimsprovider>
  <displayname>Azure Active Directory</displayname>
  <technicalprofiles>
    <technicalprofile id="AAD-UserWriteUsingAlternativeSecurityId">
      <inputclaims>
        <inputclaim claimtypereferenceid="email" partnerclaimtype="signInNames.emailAddress" required="true"></inputclaim>
        <inputclaim claimtypereferenceid="givenName" partnerclaimtype="givenName"></inputclaim>
        <inputclaim claimtypereferenceid="surname" partnerclaimtype="surname"></inputclaim>
      </inputclaims>
      ...
    </technicalprofile>

    <technicalprofile id="GetUserProfile">
      ...
    </technicalprofile>

    <technicalprofile id="SelfAsserted-LocalAccountSignin-Email">
      ...
    </technicalprofile>

    <claimsproviderselections>
      <claimsproviderselection targetclaimsexchangeid="AAD-UserWriteUsingAlternativeSecurityId"></claimsproviderselection>
    </claimsproviderselections>

    <claimsexchanges>
      <claimsexchange id="GetDisplayName" technicalprofilereferenceid="GetUserProfile"></claimsexchange>
      <claimsexchange id="GetEmail" technicalprofilereferenceid="SelfAsserted-LocalAccountSignin-Email"></claimsexchange>
      <claimsexchange id="AlternativeSecurityId" technicalprofilereferenceid="AAD-UserWriteUsingAlternativeSecurityId"></claimsexchange>
    </claimsexchanges>
  </technicalprofiles>
</claimsprovider>

    En este ejemplo, se agregan perfiles técnicos ClaimsExchange para mapear las claims de entrada email, givenName y surname a los PartnerClaimTypes correspondientes requeridos por el perfil técnico AAD-UserWriteUsingAlternativeSecurityId. Los perfiles técnicos GetUserProfile y SelfAsserted-LocalAccountSignin-Email se utilizan para obtener los valores de givenName, surname y email del proveedor de identidad del usuario y del usuario mismo. Las selecciones de proveedores de claims se utilizan para seleccionar el ClaimsProvider y ClaimsExchange requeridos para el perfil técnico AAD-UserWriteUsingAlternativeSecurityId. Finalmente, los pasos de orquestación ClaimsExchanges se utilizan para ejecutar los perfiles técnicos GetUserProfile, SelfAsserted-LocalAccountSignin-Email y AAD-UserWriteUsingAlternativeSecurityId en el orden requerido.

    En cuanto a la vinculación automática de una identidad federada a una cuenta local existente con la misma dirección de correo electrónico, puedes utilizar el perfil técnico AAD-UserReadUsingEmailAddress para obtener el ID de objeto del usuario existente mediante la dirección de correo electrónico. Luego, puedes utilizar el perfil técnico AAD-UserWriteUsingAlternativeSecurityId para escribir el ID de seguridad alternativo con el ID de objeto del usuario existente, vinculando así la identidad federada con la cuenta local existente. Puedes agregar los perfiles técnicos ClaimsExchange requeridos y los pasos de orquestación ClaimsProviderSelection y ClaimsExchanges en el paso de orquestación UserWriteUsingAlternativeSecurityId.

    Ten en cuenta que deberás agregar lógica de validación personalizada para asegurarte de que la dirección de correo electrónico proporcionada por el usuario coincida con la dirección de correo electrónico de la cuenta local existente. Puedes utilizar un perfil técnico ClaimsTransformation para transformar las claims de entrada y utilizarlas en la lógica de validación personalizada.

Comments are closed.