Recientemente, un cliente quería permitir a sus usuarios seleccionar direcciones SMTP alternativas específicas para su eliminación a través del portal FIM.
Consideramos la posibilidad de ampliar el esquema para añadir varios atributos a cada usuario que contengan las direcciones smtp alternativas y la bandera correspondiente para indicar una solicitud de eliminación, pero como cada usuario podría tener docenas de direcciones alternativas, la solución no sería escalable.
Cuando se utilizan los controles de casilla de verificación o botón de radio en FIM, hay dos opciones para rellenar los valores disponibles en estas listas. Una es codificarlo en el RCDC, lo que funciona si hay un conjunto de valores que se aplicarían globalmente a todos los usuarios. Con las direcciones de correo electrónico, esto no funcionaría. La otra opción es crear un nuevo tipo de recurso que permita gestionar esos valores. Añadir un tipo de recurso "smtp secundario" habría aumentado mucho el tamaño del metaverso y los tiempos de sincronización. Parecía como utilizar un mazo para clavar un clavo suelto de la tarima.
Así que desempolvamos nuestras habilidades de desarrollador de SharePoint y creamos una función personalizada.
El resultado es una página que parece formar parte del portal FIM, pero que en realidad está utilizando el control de casilla aspx y valores almacenados en una cadena indexada. Simplemente añadimos un enlace a la página en el RCDC del usuario:
La colección de direcciones proxy se escribe desde AD al servicio FIM a través de FIM Sync en un atributo multivalor de cadena indexada. La función personalizada lee estos valores y presenta al usuario una lista de opciones con casillas de verificación. Al deseleccionar un elemento y enviarlo, se actualiza el atributo de recopilación de direcciones proxy para que pueda volver a AD.
[Cabe señalar que esta función se encuentra en una página de SharePoint y no forma parte del RCDC].
Utilizamos la página maestra de ILM2 para que la lista de casillas de verificación tuviera el aspecto del portal FIM. A continuación, alojamos una página con la función desplegada en una biblioteca del sitio SharePoint del portal.
La parte complicada era conceder al código acceso al modelo de objetos de SharePoint para mantener la sesión existente del usuario y no tener que solicitar una nueva autenticación. Una forma rápida y sucia de hacer esto es simplemente establecer el nivel de confianza del sitio en completo, pero eso es un riesgo de seguridad. Haciendo esto se otorgaría plena confianza a todos los ensamblados en el servidor. Otro método rápido es instalar el ensamblado en el GAC. Esto le otorga confianza total en todas las aplicaciones del servidor, lo que obviamente es un rango de permisos más amplio del que necesita.
La solución fue personalizar la seguridad de acceso al código con un archivo de políticas personalizado. Este archivo nos permite conceder un nivel de confianza específico sólo para nuestro ensamblado. El permiso se concede al código y no al usuario que ejecuta el código.
En primer lugar, copiamos el archivo wss_minimal.config en el archivo CONFIG del 14-hive y lo llamamos wss_custom.config.
A continuación, se modificó como se describe a continuación:
Usando el Visual Studio command prompt, extrajimos el Public Key Blob a un archivo de texto. Después de navegar hasta el directorio que contenía nuestro archivo .snk para nuestro ensamblado, ejecutamos estos comandos:
Sn -p MiNombreDeArchivo.snk PKOnly.snk
Sn -tp PKOnly.snk > PKOnly.txt
El archivo de texto resultante tenía un valor muy largo después de la frase "La clave pública es" para copiar.
A continuación, copiamos ese valor en una nueva sección del archivo wss_custom:
<CodeGroup class=”UnionCodeGroup” version=”1″ PermissionSetName=”FullTrust”>
<IMembershipCondition class=”StrongNameMembershipCondition” version=”1″ PublicKeyBlob=”[Paste the really long value here]”></IMembershipCondition>
</CodeGroup>
Aquí tienes una captura de pantalla:
In the web.config file, we added this to the <securityPolicy> settings:
<trustLevel name=”WSS_Custom” policyFile=”C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\config\wss_custom.config” />
A continuación, cambiamos el nivel de confianza en el archivo web.config a WSS_Custom.
<trust level=”WSS_Custom” originUrl=”” />
