Más consejos para solucionar problemas en aplicaciones de elevada confianza en SharePoint 2013
Artículo original publicado el viernes 2 de noviembre de 2012
Hola, soy muy de aplicaciones, me gusta desarrollar, pero, francamente, puedo quedarme afónico gritando a mi equipo si tengo que averiguar de dónde surge otro problema del tipo "El emisor del token no es un emisor de confianza" en mis nuevas aplicaciones de SharePoint. Para ayudarlo a cuidar su propia voz (y cordura), haré una lista aquí de las cosas que busco cuando tengo este problema. A medida que descubra nuevas y emocionantes formas de invocar este error y resolverlo, actualizaré esta publicación y colocaré el indicador "¡ACTUALIZADO!" debajo.
Es importante recordar que, cuando digo "aplicación de elevada confianza", significa que usted NO está usando ACS como agente de confianza para su aplicación de SharePoint; en lugar de eso, está creando el token de OAuth y lo está firmando con su propio certificado. Sé que este proceso está documentado en algún lugar, así que no intentaré describirlo aquí de nuevo. Asumiré que lo ha leído, lo ha intentado, y ahora está listo para saludar con un dedo a su monitor. Así que, dicho esto, estas son algunas situaciones en las que he visto que este error ocurra:
- Agregar a la lista SPTrustedRootAuthority: cuando usa un certificado para firmar sus tokens de OAuth, tiene que crear una New-SPTrustedRootAuthority. Como la New-SPTrustedIdentityTokenIssuer de SharePoint 2010, tiene que agregar el certificado de firma de token y todos los certificados de la cadena a la lista de SharePoint de entidades de confianza. Puede seguir los mismos pasos para este proceso como he descrito en esta publicación: https://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx. Ignore las partes en que se habla de exportar el certificado desde ADFS. Asumo que ha creado su certificado para sus aplicaciones de elevada confianza a través de otro medio: CA raíz pública como GoDaddy, VeriSign, etc., certificado autofirmado o certificado extendido por dominio.
- Todos los caracteres del ID de cliente están en mayúsculas: como he descrito en otra publicación, asegúrese de NO usar letras mayúsculas cuando coloca el ID de cliente en el archivo AppManifest.xml de su aplicación o en el web.config de su aplicación web si está construyendo una solución autohospedada. Para obtener más detalles, vea https://blogs.technet.com/b/speschka/archive/2012/07/28/an-important-tip-about-client-id-values-for-s2s-apps-in-sharepoint-2013.aspx.
- El emisor de token no está configurado como agente de confianza: también he descrito este problema en otra publicación aquí: https://blogs.technet.com/b/speschka/archive/2012/09/27/another-apps-for-sharepoint-tip-with-the-error-quot-the-issuer-of-the-token-is-not-a-trusted-issuer-quot.aspx. La clave de esto es asegurarse, cuando cree su New-SPTrustedSecurityTokenIssuer, de incluir la marca -IsTrustBroker.
- ¡ACTUALIZADO!: Falta la clave del ID de usuario en web.config: para usar la característica de agente de confianza de aplicaciones en SharePoint 2013, su aplicación tiene que saber cuál es el ID de usuario del agente de confianza cuando crea el token JWT que envía a SharePoint. La forma en que lo sabe es buscando en web.config una propiedad de aplicación llamada IssuerId. Va al mismo lugar del archivo web.config de su aplicación como ClientId, ClientSecret, etc. Se ve así: lt;add key="IssuerId" value="e9134021-0180-4b05-9e7e-0a9e5a524965"/>.
- ¡ACTUALIZADO!: Uso de la versión RTM Preview de herramientas de Office para Visual Studio: hay un pequeño error en los bits de RTM Preview, que está arreglado en Preview 2. El código que envía ese token de autorización a SharePoint no busca el elemento ID de usuario en el archivo web.config, sino que envía un valor distinto. El valor que se envía y el motivo por el que se envía no es lo importante; lo importante ES que cuando trabaje con estos aspectos con esta versión de las herramientas lo haga siempre usando el valor ID de usuario para el SPTrustedSecurityTokenIssuer en la clave del ID de cliente de su archivo web.config. A medida que obtiene los bits de Preview 2, instálelos de inmediato y cambie el ID de cliente a un único GUID que usted cree y registre (con Register-SPAppPrincipal, como se explica a continuación). Los ID de cliente no tienen que ser todos iguales porque identifican qué aplicación firmó el token OAuth y se usan a lo largo de la interfaz de usuario de SharePoint. Si alguna vez necesita solucionar problemas o hacer una auditoría, experimentará problemas si todas las aplicaciones usan el mismo valor.
También hay un problema relacionado que conviene destacar: supongamos que usted "cree" que ha resuelto este error, pero después recibe el error Acceso denegado cuando intenta recuperar el contenido de un sitio de SharePoint en su aplicación autohospedada. Esto puede significar que:
- El valor del ID de cliente de su archivo AppManifest.xml para su aplicación de SharePoint no coincide con el valor del ID de cliente del archivo web.config de su aplicación autohospedada. Estamos haciendo mejoras en las herramientas de Visual Studio que deberían solucionar este problema.
Una pregunta casi igual de buena es cómo averiguar el origen de cosas como estas cuando suceden. Si fuese fácil, yo no estaría afónico ni le enseñaría un dedo a mi monitor. Pero estos son los mejores orígenes de datos que he encontrado hasta ahora para usarlos cuando ocurra este problema. De nuevo, a medida que encuentre nuevas cosas, las agregaré a la lista:
- Registros de ULS: un eterno favorito, especialmente durante las fiestas, me gusta abrir los registros de ULS y admirar el volumen de datos. De acuerdo, eso fue sarcasmo. Pero lo que realmente puede hacer es ir a Administración central, Supervisión, Configurar el registro de diagnóstico. Expanda la categoría de SharePoint Foundation y seleccione los siguientes elementos: Autenticación de aplicación, Autenticación de aplicación, Autorización de autenticación y Autenticación de notificaciones. Configure el registro y nivel de seguimiento como Detallado para estos sujetos y guarde sus cambios, e intente lanzar su aplicación de nuevo. Tome una de las muchas herramientas de visión de registro ULS para ver cómo llega y se procesa su solicitud. Es una buena forma de recopilar sugerencias sobre problemas en la autenticación de su aplicación.
- Fiddler: también un favorito de los fanes, Fiddler es muy útil para estas situaciones. Lo que usted verá más a menudo es un error no autorizado 401 (como cuando el problema subyacente es "El emisor del token no es un emisor de confianza"). Si mira el último marco de la solicitud y hace clic en la pestaña Encabezados en el marco Respuesta, verá una cookie WWW-Authenticate como esta: Bearer realm="8a96481b-6c65-4e78-b2ef-a446adb79b59",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="<e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59,00000003-0000-0ff1-ce00-000000000000@8a96481b-6c65-4e78-b2ef-a446adb79b59>" Entonces, ¿qué puede tomar de esto? Sé con solo ver esto que espera que el valor de mi ID de cliente sea e9134021-0180-4b05-9e7e-0a9e5a524965 y espera que mi dominio sea 8a96481b-6c65-4e78-b2ef-a446adb79b59. El valor del ID de cliente es fácil de revisar: puedo buscar en mi archivo AppManifest.xml y web.config mi aplicación autohospedada. Es muy poco probable que su dominio sea erróneo, pero siempre puede comprobarlo ejecutando este PowerShell:
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$realm
Eso lo llevará a la pantalla, sin importar cuál sea su dominio. Finalmente, hay una cosa más que puede hacer para verificar: asegúrese de tener una appPrincipal creada para el ID de cliente que está usando. De nuevo, aquí hay un PowerShell que puede usar para revisarlo, usando mi información de encabezado WWW-Authenticate de antes:
Get-SPAppPrincipal -NameIdentifier <e9134021-0180-4b05-9e7e-0a9e5a524965@8a96481b-6c65-4e78-b2ef-a446adb79b59> -Site https://foo
Si recibe un error o no obtiene ningún resultado, sabrá que no tiene un SPAppPrincipal válido, así que tendrá que crear uno usando PowerShell. Para terminar, veremos un ejemplo de esto:
$clientId = "un guid que usted crea"
$spurl ="https://foo"
$spsite = Get-SPSite $spurl
$realm = Get-SPAuthenticationRealm -ServiceContext $spsite
$fullAppIdentifier = $clientId + <'@'> + $realm
$appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site $spsite.OpenWeb() -DisplayName "Mi aplicación atractiva"
Bien, por hoy he terminado con mi lista de consejos para solucionar problemas de aplicaciones de elevada confianza. Cuando tenga más novedades, actualizaré esta publicación.
Esta entrada de blog es una traducción. Puede ver el artículo original en More TroubleShooting Tips for High Trust Apps on SharePoint 2013