Inscripción de dispositivos de autenticación federados
En esta sección se proporciona un ejemplo del protocolo de inscripción de dispositivos móviles mediante la directiva de autenticación federada. Cuando la directiva de autenticación se establece en Federada, el cliente de inscripción usa el agente de autenticación web para obtener un token de seguridad. El cliente de inscripción llama a la API del agente de autenticación web dentro del mensaje de respuesta para iniciar el proceso. El servidor debe compilar las páginas del agente de autenticación web para que se ajusten a la pantalla del dispositivo y debe ser coherente con la interfaz de usuario de inscripción existente. El cliente de inscripción usa el token de seguridad opaco que se devuelve desde el agente como página final como secreto de seguridad del dispositivo durante la llamada a la solicitud de certificado de cliente.
El <AuthenticationServiceURL> elemento que el mensaje de respuesta de detección especifica la dirección URL de inicio de la página del agente de autenticación web.
Para obtener más información sobre el protocolo de inscripción de dispositivos móviles de Microsoft para Windows, consulte [MS-MDE2]: Protocolo de inscripción de dispositivos móviles versión 2.
Nota
Para obtener la lista de escenarios de inscripción no admitidos en Windows, consulte Escenarios de inscripción no admitidos.
Servicio de detección
El servicio web de detección proporciona la información de configuración necesaria para que un usuario inscriba un teléfono con un servicio de administración. El servicio es un servicio web restful a través de HTTPS (solo autenticación de servidor).
Nota
El administrador del servicio de detección debe crear un host con la dirección enterpriseenrollment.<domain_name>.com.
El flujo de detección automática del dispositivo usa el nombre de dominio de la dirección de correo electrónico que se envió a la pantalla de configuración de Workplace durante el inicio de sesión. El sistema de detección automática construye un URI que usa este nombre de host anexando el subdominio enterpriseenrollment al dominio de la dirección de correo electrónico y anexando la ruta de acceso /EnrollmentServer/Discovery.svc. Por ejemplo, si la dirección de correo electrónico es sample@contoso.com, el URI resultante para la primera solicitud Get sería: http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc.
La primera solicitud es una solicitud HTTP GET estándar.
En el ejemplo siguiente se muestra una solicitud a través de HTTP GET al servidor de detección dado user@contoso.com como dirección de correo electrónico.
Request Full Url: http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
Content Type: unknown
Header Byte Count: 153
Body Byte Count: 0
GET /EnrollmentServer/Discovery.svc HTTP/1.1
User-Agent: Windows Phone 8 Enrollment Client
Host: EnterpriseEnrollment.contoso.com
Pragma: no-cache
Request Full Url: http://EnterpriseEnrollment.contoso.com/EnrollmentServer/Discovery.svc
Content Type: text/html
Header Byte Count: 248
Body Byte Count: 0
HTTP/1.1 200 OK
Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/html
Content-Length: 0
Una vez que el dispositivo obtiene una respuesta del servidor, el dispositivo envía una solicitud POST a enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc. Después de obtener otra respuesta del servidor (que debe indicar al dispositivo dónde está el servidor de inscripción), el siguiente mensaje enviado desde el dispositivo es al enterpriseenrollment.<domain_name> servidor de inscripción.
Se aplica la siguiente lógica:
- El dispositivo primero intenta HTTPS. Si el dispositivo no confía en el certificado del servidor, se produce un error en el intento HTTPS.
- Si se produce un error, el dispositivo intenta HTTP para ver si se le redirige:
- Si no se redirige el dispositivo, se solicita al usuario la dirección del servidor.
- Si se redirige el dispositivo, se le pedirá al usuario que permita la redirección.
En el ejemplo siguiente se muestra una solicitud a través de un comando HTTP POST al servicio web de detección proporcionado user@contoso.com como dirección de correo electrónico.
https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc
En el ejemplo siguiente se muestra la solicitud del servicio de detección.
<?xml version="1.0"?>
<s:Envelope xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:s="http://www.w3.org/2003/05/soap-envelope">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/Discover
</a:Action>
<a:MessageID>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://ENROLLTEST.CONTOSO.COM/EnrollmentServer/Discovery.svc
</a:To>
</s:Header>
<s:Body>
<Discover xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment/">
<request xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<EmailAddress>user@contoso.com</EmailAddress>
<OSEdition>3</OSEdition>
<!-- New -->
<RequestVersion>3.0</RequestVersion>
<!-- Updated -->
<DeviceType>WindowsPhone</DeviceType>
<!-- Updated -->
<ApplicationVersion>10.0.0.0</ApplicationVersion>
<AuthPolicies>
<AuthPolicy>OnPremise</AuthPolicy>
<AuthPolicy>Federated</AuthPolicy>
</AuthPolicies>
</request>
</Discover>
</s:Body>
</s:Envelope>
La respuesta de detección tiene el formato XML e incluye los campos siguientes:
- Dirección URL del servicio de inscripción (EnrollmentServiceUrl): especifica la dirección URL del punto de conexión de inscripción que expone el servicio de administración. El dispositivo debe llamar a esta dirección URL una vez autenticado el usuario. Este campo es obligatorio.
- Directiva de autenticación (AuthPolicy): indica qué tipo de autenticación es necesaria. Para el servidor MDM, OnPremise es el valor admitido, lo que significa que el usuario se autentica al llamar a la dirección URL del servicio de administración. Este campo es obligatorio.
- En Windows, Federated se agrega como otro valor admitido. Esta adición permite al servidor usar web Authentication Broker para realizar la autenticación de usuario personalizada y el término de aceptación de uso.
Nota
La respuesta del servidor HTTP no debe establecer Transfer-Encoding en Fragmentado; debe enviarse como un mensaje.
Cuando la directiva de autenticación está establecida en Federada, el cliente de inscripción usa Web Authentication Broker (WAB) para obtener un token de seguridad. El servicio de detección proporciona la dirección URL de la página de inicio de WAB en el mensaje de respuesta. El cliente de inscripción llama a la API de WAB dentro del mensaje de respuesta para iniciar el proceso de WAB. Las páginas WAB son páginas web hospedadas por el servidor. El servidor debe compilar esas páginas para que quepan bien en la pantalla del dispositivo y ser lo más coherente posible con otras compilaciones de la interfaz de usuario de inscripción de MDM. El cliente de inscripción usa el token de seguridad opaco que se devuelve desde WAB como página final como secreto de seguridad del dispositivo durante la llamada a la solicitud de inscripción de certificados de cliente.
Nota
En lugar de confiar en la cadena del agente de usuario que se pasa durante la autenticación para obtener información, como la versión del sistema operativo, use las siguientes instrucciones:
- Analice la versión del sistema operativo a partir de los datos enviados durante la solicitud de detección.
- Anexe la versión del sistema operativo como parámetro en AuthenticationServiceURL.
- Analice la versión del sistema operativo desde AuthenticiationServiceURL cuando el sistema operativo envíe la respuesta para la autenticación.
Se introduce una nueva etiqueta XML, AuthenticationServiceUrl, en discoveryResponse XML para permitir que el servidor especifique la dirección URL de inicio de la página WAB. Para la autenticación federada, esta etiqueta XML debe existir.
Nota
El cliente de inscripción es independiente con respecto a los flujos de protocolo para autenticar y devolver el token de seguridad. Aunque el servidor puede solicitar las credenciales de usuario directamente o escribir en un protocolo de federación con otro servidor y servicio de directorio, el cliente de inscripción es independiente de todo esto. Para seguir siendo independientes, todos los flujos de protocolo relacionados con la autenticación que implican al cliente de inscripción son pasivos, es decir, implementados por el explorador.
Los siguientes son los requisitos explícitos para el servidor.
- El
<DiscoveryResponse>``<AuthenticationServiceUrl>elemento debe admitir HTTPS. - El servidor de autenticación debe usar un certificado raíz de confianza del dispositivo. De lo contrario, se produce un error en la llamada WAP.
- WP no admite la autenticación integrada de Windows (WIA) para ADFS durante la autenticación WAB. ADFS 2012 R2 si se usa debe configurarse para no intentar WIA para el dispositivo Windows.
El cliente de inscripción emite una solicitud HTTPS como se indica a continuación:
AuthenticationServiceUrl?appru=<appid>&login_hint=<User Principal Name>
-
<appid>es del formularioms-app://string -
<User Principal Name>es el nombre del usuario que se inscribe, por ejemplo, user@constoso.com como entrada del usuario en una página de inicio de sesión de inscripción. El valor de este atributo actúa como una sugerencia que usa el servidor de autenticación como parte de la autenticación.
Una vez completada la autenticación, el servidor de autenticación debe devolver un documento de formulario HTML con una acción de método POST de appid identificada en el parámetro de cadena de consulta.
Nota
Para que una aplicación sea compatible con una directiva de seguridad de contenido estricta, normalmente es necesario realizar algunos cambios en las plantillas HTML y el código del lado cliente, agregar el encabezado de directiva y probar que todo funciona correctamente una vez implementada la directiva.
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Vary: Accept-Encoding
Content-Length: 556
<!DOCTYPE>
<html>
<head>
<title>Working...</title>
<script>
function formSubmit() {
document.forms[0].submit();
}
window.onload=formSubmit;
</script>
</head>
<body>
<!-- appid below in post command must be same as appid in previous client https request. -->
<form method="post" action="ms-app://appid">
<p><input type="hidden" name="wresult" value="token value"/></p>
<input type="submit"/>
</form>
</body>
</html>
El servidor tiene que enviar un post a una dirección URL de redireccionamiento del formulario ms-app://string (el esquema de dirección URL es ms-app) como se indica en la acción del método POST. El valor del token de seguridad es la cadena http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary codificada en base64 contenida en el <wsse:BinarySecurityToken> atributo EncodingType. Windows codifica el archivo binario cuando lo envía de vuelta al servidor de inscripción, en el formato que solo está codificado en HTML. Esta cadena es opaca para el cliente de inscripción; el cliente no interpreta la cadena.
En el ejemplo siguiente se muestra una respuesta recibida del servicio web de detección que requiere autenticación a través de WAB.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoveryService/DiscoverResponse
</a:Action>
<ActivityId>
d9eb2fdd-e38a-46ee-bd93-aea9dc86a3b8
</ActivityId>
<a:RelatesTo>urn:uuid: 748132ec-a575-4329-b01b-6171a9cf8478</a:RelatesTo>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<DiscoverResponse xmlns="http://schemas.microsoft.com/windows/management/2012/01/enrollment">
<DiscoverResult>
<AuthPolicy>Federated</AuthPolicy>
<EnrollmentVersion>3.0</EnrollmentVersion>
<EnrollmentPolicyServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentPolicyServiceUrl>
<EnrollmentServiceUrl>
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</EnrollmentServiceUrl>
<AuthenticationServiceUrl>
https://portal.manage.contoso.com/LoginRedirect.aspx
</AuthenticationServiceUrl>
</DiscoverResult>
</DiscoverResponse>
</s:Body>
</s:Envelope>
Servicio web de directiva de inscripción
El servicio de directivas es opcional. De forma predeterminada, si no se especifica ninguna directiva, la longitud mínima de la clave es de 2 k y el algoritmo hash es SHA-1.
Este servicio web implementa la especificación X.509 Certificate Enrollment Policy Protocol (MS-XCEP) que permite personalizar la inscripción de certificados para que coincida con las diferentes necesidades de seguridad de las empresas en momentos diferentes (agilidad criptográfica). El servicio procesa el mensaje GetPolicies desde el cliente, autentica el cliente y devuelve directivas de inscripción coincidentes en el mensaje GetPoliciesResponse.
Para la directiva de autenticación federada, la credencial del token de seguridad se proporciona en un mensaje de solicitud mediante el <wsse:BinarySecurityToken> elemento [WSS]. El token de seguridad se recupera como se describe en la sección de respuesta de detección. La información de autenticación es la siguiente:
- wsse:Security: el cliente de inscripción implementa el elemento definido en la
<wsse:Security>sección 5 de [WSS]. El<wsse:Security>elemento debe ser un elemento secundario del<s:Header>elemento . - wsse:BinarySecurityToken: el cliente de inscripción implementa el elemento definido en la
<wsse:BinarySecurityToken>sección 6.3 de [WSS]. El<wsse:BinarySecurityToken>elemento debe incluirse como elemento secundario del<wsse:Security>elemento en el encabezado SOAP.
Como se describió en la sección de respuesta de detección, la inclusión del <wsse:BinarySecurityToken> elemento es opaca para el cliente de inscripción y el cliente no interpreta la cadena y el servidor de autenticación de tokens de seguridad acuerda la inclusión del elemento (como se identifica en el <AuthenticationServiceUrl> elemento de <DiscoveryResponse> y el servidor de empresa).
El <wsse:BinarySecurityToken> elemento contiene una cadena codificada en base64. El cliente de inscripción usa el token de seguridad recibido del servidor de autenticación y base64 codifica el token para rellenar el <wsse:BinarySecurityToken> elemento.
wsse:BinarySecurityToken/attributes/ValueType: el
<wsse:BinarySecurityToken>atributo ValueType debe serhttp://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.wsse:BinarySecurityToken/attributes/EncodingType: el
<wsse:BinarySecurityToken>atributo EncodingType debe serhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.
El ejemplo siguiente es una solicitud de directiva de inscripción con un token de seguridad recibido como credencial de cliente.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy/IPolicy/GetPolicies
</a:Action>
<a:MessageID>urn:uuid:72048B64-0F19-448F-8C2E-B4C661860AA0</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://enrolltest.contoso.com/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:BinarySecurityToken ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
B64EncodedSampleBinarySecurityToken
</wsse:BinarySecurityToken>
</wsse:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetPolicies xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy">
<client>
<lastUpdate xsi:nil="true"/>
<preferredLanguage xsi:nil="true"/>
</client>
<requestFilter xsi:nil="true"/>
</GetPolicies>
</s:Body>
</s:Envelope>
Una vez autenticado el usuario, el servicio web recupera la plantilla de certificado con la que el usuario debe inscribirse y crea directivas de inscripción basadas en las propiedades de la plantilla de certificado. Puede encontrar un ejemplo de la respuesta en MSDN.
MS-XCEP admite directivas de inscripción flexibles mediante varios tipos y atributos complejos. En el caso del dispositivo Windows, primero admitiremos las directivas minimalKeyLength, hashAlgorithmOIDReference y CryptoProviders. HashAlgorithmOIDReference tiene OID y OIDReferenceID relacionados y policySchema en GetPolicesResponse. PolicySchema hace referencia a la versión de la plantilla de certificado. La versión 3 de MS-XCEP admite algoritmos hash.
Nota
La respuesta del servidor HTTP no debe establecer Transfer-Encoding en Fragmentado; debe enviarse como un mensaje.
En el fragmento de código siguiente se muestra la respuesta del servicio web de directiva.
<s:Envelope
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy/IPolicy/GetPoliciesResponse
</a:Action>
<a:RelatesTo>urn:uuid: 69960163-adad-4a72-82d2-bb0e5cff5598</a:RelatesTo>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<GetPoliciesResponse
xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollmentpolicy">
<response>
<policyID />
<policyFriendlyName xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<nextUpdateHours xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<policiesNotChanged xsi:nil="true"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<policies>
<policy>
<policyOIDReference>0</policyOIDReference>
<cAs xsi:nil="true" />
<attributes>
<commonName>CEPUnitTest</commonName>
<policySchema>3</policySchema>
<certificateValidity>
<validityPeriodSeconds>1209600</validityPeriodSeconds>
<renewalPeriodSeconds>172800</renewalPeriodSeconds>
</certificateValidity>
<permission>
<enroll>true</enroll>
<autoEnroll>false</autoEnroll>
</permission>
<privateKeyAttributes>
<minimalKeyLength>2048</minimalKeyLength>
<keySpec xsi:nil="true" />
<keyUsageProperty xsi:nil="true" />
<permissions xsi:nil="true" />
<algorithmOIDReference xsi:nil="true" />
<cryptoProviders xsi:nil="true" />
</privateKeyAttributes>
<revision>
<majorRevision>101</majorRevision>
<minorRevision>0</minorRevision>
</revision>
<supersededPolicies xsi:nil="true" />
<privateKeyFlags xsi:nil="true" />
<subjectNameFlags xsi:nil="true" />
<enrollmentFlags xsi:nil="true" />
<generalFlags xsi:nil="true" />
<hashAlgorithmOIDReference>0</hashAlgorithmOIDReference>
<rARequirements xsi:nil="true" />
<keyArchivalAttributes xsi:nil="true" />
<extensions xsi:nil="true" />
</attributes>
</policy>
</policies>
</response>
<cAs xsi:nil="true" />
<oIDs>
<oID>
<value>1.3.14.3.2.29</value>
<group>1</group>
<oIDReferenceID>0</oIDReferenceID>
<defaultName>szOID_OIWSEC_sha1RSASign</defaultName>
</oID>
</oIDs>
</GetPoliciesResponse>
</s:Body>
</s:Envelope>
Servicio web de inscripción
Este servicio web implementa el protocolo MS-WSTEP. Procesa el mensaje RequestSecurityToken (RST) del cliente, autentica al cliente, solicita el certificado de la CA y lo devuelve en RequestSecurityTokenResponse (RSTR) al cliente. Además del certificado emitido, la respuesta también contiene las configuraciones necesarias para aprovisionar DMClient.
RequestSecurityToken (RST) debe tener la credencial de usuario y una solicitud de certificado. La credencial de usuario en un sobre SOAP de RST es la misma que en GetPolicies y puede variar en función de si la directiva de autenticación es OnPremise o Federated. BinarySecurityToken en un cuerpo SOAP de RST contiene una solicitud de certificado PKCS#10 codificada en Base64, que el cliente genera en función de la directiva de inscripción. El cliente podría haber solicitado una directiva de inscripción mediante MS-XCEP antes de solicitar un certificado mediante MS-WSTEP. Si la entidad de certificación (CA) acepta la solicitud de certificado PKCS#10 (la longitud de la clave, el algoritmo hash, etc., coinciden con la plantilla de certificado), el cliente puede inscribirse correctamente.
RequestSecurityToken usa un TokenType personalizado (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken), porque nuestro token de inscripción es más que un certificado X.509 v3. Para obtener más información, consulte la sección Respuesta.
El RST también puede especificar muchos elementos AdditionalContext, como DeviceType y Version. En función de estos valores, por ejemplo, el servicio web puede devolver la configuración de DM específica del dispositivo y específica de la versión.
Nota
El servicio de directivas y el servicio de inscripción deben estar en el mismo servidor; es decir, deben tener el mismo nombre de host.
En el ejemplo siguiente se muestra la solicitud de servicio web de inscripción para la autenticación federada.
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
xmlns:ac="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<s:Header>
<a:Action s:mustUnderstand="1">
http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RST/wstep
</a:Action>
<a:MessageID>urn:uuid:0d5a1441-5891-453b-becf-a2e5f6ea3749</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">
https://enrolltest.contoso.com:443/ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC
</a:To>
<wsse:Security s:mustUnderstand="1">
<wsse:BinarySecurityToken
wsse:ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken"
wsse:EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
B64EncodedSampleBinarySecurityToken
</wsse:BinarySecurityToken>
</wsse:Security>
</s:Header>
<s:Body>
<wst:RequestSecurityToken>
<wst:TokenType>
http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
</wst:TokenType>
<wst:RequestType>
http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
</wst:RequestType>
<wsse:BinarySecurityToken
ValueType="http://schemas.microsoft.com/windows/pki/2009/01/enrollment#PKCS10"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary">
DER format PKCS#10 certificate request in Base64 encoding Insterted Here
</wsse:BinarySecurityToken>
<ac:AdditionalContext xmlns="http://schemas.xmlsoap.org/ws/2006/12/authorization">
<ac:ContextItem Name="OSEdition">
<ac:Value> 4</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="OSVersion">
<ac:Value>10.0.9999.0</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceName">
<ac:Value>MY_WINDOWS_DEVICE</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="MAC">
<ac:Value>FF:FF:FF:FF:FF:FF</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="MAC">
<ac:Value>CC:CC:CC:CC:CC:CC</ac:Value>
<ac:ContextItem Name="IMEI">
<ac:Value>49015420323756</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="IMEI">
<ac:Value>30215420323756</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="EnrollmentType">
<ac:Value>Full</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceType">
<ac:Value>CIMClient_Windows</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="ApplicationVersion">
<ac:Value>10.0.9999.0</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="DeviceID">
<ac:Value>7BA748C8-703E-4DF2-A74A-92984117346A</ac:Value>
</ac:ContextItem>
<ac:ContextItem Name="TargetedUserLoggedIn">
<ac:Value>True</ac:Value>
</ac:ContextItem>
</ac:AdditionalContext>
</wst:RequestSecurityToken>
</s:Body>
</s:Envelope>
Después de validar la solicitud, el servicio web busca la plantilla de certificado asignada para el cliente, la actualiza si es necesario, envía las solicitudes PKCS#10 a la CA, procesa la respuesta de la CA, construye un formato XML de aprovisionamiento de cliente OMA y lo devuelve en RequestSecurityTokenResponse (RSTR).
Nota
La respuesta del servidor HTTP no debe establecer Transfer-Encoding en Fragmentado; debe enviarse como un mensaje.
De forma similar al TokenType en el RST, el RSTR usa un ValueType personalizado en BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), ya que el token es más que un certificado X.509 v3.
El XML de aprovisionamiento contiene:
- Los certificados solicitados (obligatorios)
- Configuración de DMClient (obligatorio)
El cliente instala el certificado de cliente, el certificado raíz de empresa y el certificado intermedio de ca si hay uno. La configuración de DM incluye el nombre y la dirección del servidor DM, el certificado de cliente que se va a usar y programa cuándo dmClient llama de vuelta al servidor.
El XML de aprovisionamiento de inscripción debe contener un máximo de un certificado raíz y un certificado de ENTIDAD de certificación intermedio que sea necesario para encadenar el certificado de cliente MDM. Se podrían aprovisionar más certificados de CA raíz e intermedios durante una sesión de OMA DM.
Cuando se aprovisionan certificados de CA raíz e intermedios, la ruta de acceso del nodo CSP compatible es: CertificateStore/Root/System para el aprovisionamiento de certificados raíz, CertificateStore/My/User para el aprovisionamiento intermedio de certificados de CA.
Este es un mensaje RSTR de ejemplo y un ejemplo de XML de aprovisionamiento de cliente OMA dentro de RSTR. Para obtener más información sobre los proveedores de servicios de configuración (CSP) que se usan en el aprovisionamiento de XML, consulte la sección Configuración empresarial, directivas y administración de aplicaciones.
En el ejemplo siguiente se muestra la respuesta del servicio web de inscripción.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:a="http://www.w3.org/2005/08/addressing"
xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action s:mustUnderstand="1" >
http://schemas.microsoft.com/windows/pki/2009/01/enrollment/RSTRC/wstep
</a:Action>
<a:RelatesTo>urn:uuid:81a5419a-496b-474f-a627-5cdd33eed8ab</a:RelatesTo>
<o:Security s:mustUnderstand="1" xmlns:o=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2012-08-02T00:32:59.420Z</u:Created>
<u:Expires>2012-08-02T00:37:59.420Z</u:Expires>
</u:Timestamp>
</o:Security>
</s:Header>
<s:Body>
<RequestSecurityTokenResponseCollection
xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<RequestSecurityTokenResponse>
<TokenType>
http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken
</TokenType>
<DispositionMessage xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment"/>
<RequestedSecurityToken>
<BinarySecurityToken
ValueType="http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
B64EncodedSampleBinarySecurityToken
</BinarySecurityToken>
</RequestedSecurityToken>
<RequestID xmlns="http://schemas.microsoft.com/windows/pki/2009/01/enrollment">0</RequestID>
</RequestSecurityTokenResponse>
</RequestSecurityTokenResponseCollection>
</s:Body>
</s:Envelope>
En el código siguiente se muestra el código XML de aprovisionamiento de ejemplo (presentado en el paquete anterior como un token de seguridad):
<wap-provisioningdoc version="1.1">
<characteristic type="CertificateStore">
<characteristic type="Root">
<characteristic type="System">
<characteristic type="Encoded Root Cert Hash Inserted Here">
<parm name="EncodedCertificate" value="B64 encoded cert insert here" />
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<characteristic type="CertificateStore">
<characteristic type="My" >
<characteristic type="User">
<characteristic type="Encoded Root Cert Hash Inserted Here">
<parm name="EncodedCertificate" value="B64EncodedCertInsertedHere" />
</characteristic>
<characteristic type="PrivateKeyContainer"/>
<!-- This tag must be present for XML syntax correctness. -->
</characteristic>
<characteristic type="WSTEP">
<characteristic type="Renew">
<!-If the datatype for ROBOSupport, RenewPeriod, and RetryInterval tags exist, they must be set explicitly. -->
<parm name="ROBOSupport" value="true" datatype="boolean"/>
<parm name="RenewPeriod" value="60" datatype="integer"/>
<parm name="RetryInterval" value="4" datatype="integer"/>
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<characteristic type="APPLICATION">
<parm name="APPID" value="w7"/>
<parm name="PROVIDER-ID" value="TestMDMServer"/>
<parm name="NAME" value="Microsoft"/>
<parm name="ADDR" value="https://DM.contoso.com:443/omadm/Windows.ashx"/>
<parm name="CONNRETRYFREQ" value="6" />
<parm name="INITIALBACKOFFTIME" value="30000" />
<parm name="MAXBACKOFFTIME" value="120000" />
<parm name="BACKCOMPATRETRYDISABLED" />
<parm name="DEFAULTENCODING" value="application/vnd.syncml.dm+wbxml" />
<parm name="SSLCLIENTCERTSEARCHCRITERIA" value="Subject=DC%3dcom%2cDC%3dmicrosoft%2cCN%3dUsers%2cCN%3dAdministrator&amp;Stores=My%5CUser"/>
<characteristic type="APPAUTH">
<parm name="AAUTHLEVEL" value="CLIENT"/>
<parm name="AAUTHTYPE" value="DIGEST"/>
<parm name="AAUTHSECRET" value="password1"/>
<parm name="AAUTHDATA" value="B64encodedBinaryNonceInsertedHere"/>
</characteristic>
<characteristic type="APPAUTH">
<parm name="AAUTHLEVEL" value="APPSRV"/>
<parm name="AAUTHTYPE" value="BASIC"/>
<parm name="AAUTHNAME" value="testclient"/>
<parm name="AAUTHSECRET" value="password2"/>
</characteristic>
</characteristic>
<characteristic type="DMClient"> <!-- In Windows 10, an enrollment server should use DMClient CSP XML to configure DM polling schedules. -->
<characteristic type="Provider">
<!-- ProviderID in DMClient CSP must match to PROVIDER-ID in w7 APPLICATION characteristics -->
<characteristic type="TestMDMServer">
<parm name="UPN" value="UserPrincipalName@contoso.com" datatype="string" />
<parm name="EntDeviceName" value="Administrator_Windows" datatype="string" />
<characteristic type="Poll">
<parm name="NumberOfFirstRetries" value="8" datatype="integer" />
<parm name="IntervalForFirstSetOfRetries" value="15" datatype="integer" />
<parm name="NumberOfSecondRetries" value="5" datatype="integer" />
<parm name="IntervalForSecondSetOfRetries" value="3" datatype="integer" />
<parm name="NumberOfRemainingScheduledRetries" value="0" datatype="integer" />
<!-- Windows 10 supports MDM push for real-time communication. The DM client long term polling schedule's retry waiting interval should be more than 24 hours (1440) to reduce the impact to data consumption and battery life. Refer to the DMClient Configuration Service Provider section for information about polling schedule parameters.-->
<parm name="IntervalForRemainingScheduledRetries" value="1560" datatype="integer" />
<parm name="PollOnLogin" value="true" datatype="boolean" />
</characteristic>
</characteristic>
</characteristic>
</characteristic>
<!-- For Windows 10, we removed EnterpriseAppManagement from the enrollment protocol. -->
</wap-provisioningdoc>
Nota
<Parm name>y<characteristic type=>los elementos en w7 APPLICATION CSP XML distinguen mayúsculas de minúsculas y deben estar en mayúsculas.En la característica application de w7, se deben proporcionar las credenciales DE CLIENTE y APPSRV en XML.
Las descripciones detalladas de esta configuración se encuentran en la sección Configuración empresarial, directivas y administración de aplicaciones de este documento.
La característica PrivateKeyContainer es necesaria y la inscripción debe estar presente en el XML de aprovisionamiento de inscripción. Otros valores importantes son los elementos de parámetro PROVIDER-ID, NAME y ADDR , que deben contener el identificador único y el nombre del proveedor de DM y la dirección donde el dispositivo se puede conectar para el aprovisionamiento de configuración. El identificador y NAME pueden ser valores arbitrarios, pero deben ser únicos.
También es importante SSLCLIENTCERTSEARCHCRITERIA, que se usa para seleccionar el certificado que se va a usar para la autenticación de cliente. La búsqueda se basa en el atributo subject del certificado de usuario firmado.
CertificateStore/WSTEP permite la renovación de certificados. Si el servidor no lo admite, no lo establezca.