• Inicio
  • Blog
  • Autenticación y autorización basadas en reclamaciones con ADFS 2.0 y SharePoint 2010

Autenticación y autorización basadas en reclamaciones con ADFS 2.0 y SharePoint 2010

Muchas notas técnicas y artículos web hablan sobre diferentes aspectos de la federación basada en reclamaciones entre ADFS 2.0 y SharePoint 2010. En este blog, nos centraremos principalmente en la asignación de reclamaciones, la configuración del proceso de autenticación y autorización.

Veamos a continuación un escenario de extremo a extremo:

1. El usuario intenta acceder a la aplicación web SharePoint 2010 basada en reclamaciones.

2. SharePoint redirige la solicitud de acceso a ADFS basándose en la configuración de SharePoint Trusted Identity Token Provider y estableciendo una relación de confianza de federación con ADFS.

$Name = New-SPClaimTypeMapping "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Nombre para mostrar" -LocalClaimType "https://schemas.contoco.com/identity/claims/name

$Role = New-SPClaimTypeMapping "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFSv2" -Description "Servicios de federación de Active Directory 2.0" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $Name, $Role -SignInUrl $signInURL -IdentifierClaim $Name.InputClaimType

Tenga en cuenta que el tipo de reclamación Nombre https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name está reservado por SharePoint. En este ejemplo, utilizamos -LocalClaimType para realizar la asignación del tipo de reclamación a https://schemas.contoso.com /identity/claims/name. Veremos la razón más adelante. En términos de SharePoint, este tipo de reclamación mapeado https://schemas.contoso.com/identity/claims/name es el llamado tipo de reclamación personalizado (tipo de reclamación no predefinido).

3. ADFS autentica al usuario, genera el token de seguridad con 2 reclamaciones y lo devuelve a SharePoint.

<saml:Attribute AttributeName=”role” AttributeNamespace=” https://schemas.microsoft.com/ws/2008/06/identity/claims”>

<saml:AttributeValue>SharePoint Users</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute AttributeName=“name“ AttributeNamespace=”https://schemas.xmlsoap.org/ws/2005/05/identity/claims”>

<saml:AttributeValue>Jake</saml:AttributeValue>

</saml:Attribute>

4. El servicio de token de seguridad de SharePoint valida el token de seguridad, consume las reclamaciones, reasigna la reclamación de nombre y también genera sus propias reclamaciones como adiciones. Todas las reclamaciones juntas se pasarán a la aplicación web basada en reclamaciones.

https://schemas.contoso.com/identity/claims/name = Jake

https://schemas.xmlsoap.org/ws/2005/05/identity/claims/role = SharePoint Users

https://schemas.microsoft.com/sharepoint/2009/08/claims/userid = 0ǵ.t|ADFSv2|Jake https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name = Jake

https://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true

Observe que SharePoint reasigna la primera reclamación basándose en la asignación de reclamaciones de la configuración.

$Name = New-SPClaimTypeMapping "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "Nombre para mostrar" -LocalClaimType "https://schemas.contoco.com/identity/claims/name

Las 3 últimas reclamaciones con tipos de reclamación predefinidos son generadas por SharePoint y los valores se calculan en función de los valores de reclamación entrantes. También se incluye la reclamación generada por SharePoint con el tipo https://schemas.xmlsoap.org/ws/2005/05/identity/claims/name. Esta es la razón por la que debemos utilizar -LocalClaimType al configurar el emisor de tokens de identidad de confianza mencionado en el paso 2. La última reclamación https://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true se basa en la declaración de autenticación del token de seguridad entrante.

5. Antes de que todas las reclamaciones pasen a la aplicación web basada en reclamaciones, SharePoint realizará una comprobación de autorización. Podemos utilizar el Selector de Personas para configurar los permisos de autorización. Sin embargo, en este blog, nos gustaría mostrar cómo utilizar powershell para implementar dicha configuración de permisos.

Por ejemplo, si queremos permitir que todos los usuarios autenticados accedan a esta aplicación web en el grupo SharePoint de "Visitantes de SharePoint Web Home" con nivel de permiso de Lectura, podemos hacer lo siguiente:

$web = Get-SPWeb "https://www.sharepoint.com:4443"

$Group = $web.SiteGroups["Visitantes de la página de inicio de SharePoint"].

$claimPrincipal =New-SPClaimsPrincipal -EncodedClaim "c:0(.s|true"

$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web

$group.AddUser($nuevoUsuario)

Observe que "c:0(.s|true" es la cadena de reivindicación codificada para "Todos los usuarios autenticados". La cadena de reivindicación codificada se basa en el formato y las reglas de asignación de reivindicaciones de SharePoint que se indican a continuación:

c -> otra reclamación (distinta de la reclamación de identidad)

( -> carácter de tipo reivindicativo de https://sharepoint.microsoft.com/claims/2009/08/isauthenticated

s -> STS local (SharePoint STS es el emisor de esta reclamación, es decir, SharePoint genera la suya propia)

true -> valor de la reclamación (recuerde https://sharepoint.microsoft.com/claims/2009/08/isauthenticated = true)

Para permitir a todos los usuarios autenticados con claim de rol "Usuarios SharePoint" acceder a esta aplicación web en el grupo SharePoint de "Visitantes SharePoint Web Home" con nivel de permiso de Lectura, podemos hacer lo siguiente:

$web = Get-SPWeb "https://www.sharepoint.com:4443"

$Group = $web.SiteGroups["Visitantes de la página de inicio de SharePoint"].

$sts = Get-SPTrustedIdentityTokenIssuer "ADFSv2"

$claimPrincipal = New-SPClaimsPrincipal -ClaimValue "Usuarios de SharePoint" -ClaimType "https://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts

$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web

$group.AddUser($nuevoUsuario)

6. Una vez autorizado el acceso, SharePoint establecerá la cookie FedAuth y redirigirá la solicitud al destino original.