Registro de dispositivos de autenticação federada
Esta secção fornece um exemplo do protocolo de inscrição de dispositivos móveis com a política de autenticação federada. Quando a política de autenticação está definida como Federado, o mediador de autenticação Web é utilizado pelo cliente de inscrição para obter um token de segurança. O cliente de inscrição chama a API do mediador de autenticação Web na mensagem de resposta para iniciar o processo. O servidor deve criar as páginas do mediador de autenticação Web para se ajustar ao ecrã do dispositivo e deve ser consistente com a IU de inscrição existente. O token de segurança opaco que é devolvido do mediador como uma página final é utilizado pelo cliente de inscrição como o segredo de segurança do dispositivo durante a chamada do pedido de certificado de cliente.
O <AuthenticationServiceURL> elemento que a mensagem de resposta de deteção especifica o URL de início da página de mediador de autenticação Web.
Para obter detalhes sobre o protocolo de inscrição de dispositivos móveis da Microsoft para Windows, consulte [MS-MDE2]: Mobile Device Enrollment Protocol Versão 2.
Observação
Para obter a lista de cenários de inscrição não suportados no Windows, veja Cenários de inscrição não suportados.
Serviço de deteção
O serviço Web de deteção fornece as informações de configuração necessárias para um utilizador inscrever um telemóvel num serviço de gestão. O serviço é um serviço Web restful através de HTTPS (apenas autenticação de servidor).
Observação
O administrador do serviço de deteção tem de criar um anfitrião com o endereço enterpriseenrollment.<domain_name>.com.
O fluxo de deteção automática do dispositivo utiliza o nome de domínio do endereço de e-mail que foi submetido para o ecrã de definições da Área de Trabalho durante o início de sessão. O sistema de deteção automática constrói um URI que utiliza este nome de anfitrião ao acrescentar o subdomínio enterpriseenrollment ao domínio do endereço de e-mail e ao acrescentar o caminho /EnrollmentServer/Discovery.svc. Por exemplo, se o endereço de e-mail for sample@contoso.com, o URI resultante para o primeiro pedido Get seria: http://enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc.
O primeiro pedido é um pedido HTTP GET padrão.
O exemplo seguinte mostra um pedido via HTTP GET para o servidor de deteção fornecido user@contoso.com como o endereço de e-mail.
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
Depois de o dispositivo receber uma resposta do servidor, o dispositivo envia um pedido POST para enterpriseenrollment.<domain_name>/EnrollmentServer/Discovery.svc. Depois de obter outra resposta do servidor (que deve indicar ao dispositivo onde está o servidor de inscrição), a mensagem seguinte enviada a partir do dispositivo é para enterpriseenrollment.<domain_name> o servidor de inscrição.
É aplicada a seguinte lógica:
- O dispositivo tenta primeiro HTTPS. Se o dispositivo não confiar no certificado do servidor, a tentativa de HTTPS falhará.
- Se isso falhar, o dispositivo tentará HTTP para ver se é redirecionado:
- Se o dispositivo não for redirecionado, é pedido ao utilizador o endereço do servidor.
- Se o dispositivo for redirecionado, é pedido ao utilizador que permita o redirecionamento.
O exemplo seguinte mostra um pedido através de um comando HTTP POST para o serviço Web de deteção fornecido user@contoso.com como o endereço de e-mail
https://EnterpriseEnrollment.Contoso.com/EnrollmentServer/Discovery.svc
O exemplo seguinte mostra o pedido do serviço de deteção.
<?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>
A resposta de deteção está no formato XML e inclui os seguintes campos:
- URL do serviço de inscrição (EnrollmentServiceUrl) – especifica o URL do ponto final de inscrição que é exposto pelo serviço de gestão. O dispositivo deve chamar este URL depois de o utilizador ter sido autenticado. Este campo é obrigatório.
- Política de autenticação (AuthPolicy) – indica que tipo de autenticação é necessária. Para o servidor MDM, OnPremise é o valor suportado, o que significa que o utilizador é autenticado ao chamar o URL do serviço de gestão. Este campo é obrigatório.
- No Windows, Federado é adicionado como outro valor suportado. Esta adição permite ao servidor utilizar o Mediador de Autenticação Web para efetuar a autenticação personalizada do utilizador e o termo de aceitação de utilização.
Observação
A resposta do servidor HTTP não pode definir Transfer-Encoding como Segmentado; tem de ser enviada como uma mensagem.
Quando a política de autenticação está definida como Federada, o Mediador de Autenticação Web (WAB) é utilizado pelo cliente de inscrição para obter um token de segurança. O URL da página inicial do WAB é fornecido pelo serviço de deteção na mensagem de resposta. O cliente de inscrição chama a API WAB na mensagem de resposta para iniciar o processo wab. As páginas WAB são páginas Web alojadas no servidor. O servidor deve criar essas páginas para se ajustarem bem ao ecrã do dispositivo e serem o mais consistentes possível com outras compilações na IU de inscrição MDM. O token de segurança opaco que é devolvido da WAB como uma página final é utilizado pelo cliente de inscrição como o segredo de segurança do dispositivo durante a chamada do pedido de inscrição de certificados de cliente.
Observação
Em vez de depender da cadeia de agente do utilizador que é transmitida durante a autenticação para obter informações, como a versão do SO, utilize a seguinte documentação de orientação:
- Analise a versão do SO dos dados enviados durante o pedido de deteção.
- Acrescente a versão do SO como um parâmetro no AuthenticationServiceURL.
- Analise a versão do SO do AuthenticiationServiceURL quando o SO enviar a resposta para autenticação.
Uma nova etiqueta XML, AuthenticationServiceUrl, é introduzida no XML DiscoveryResponse para permitir que o servidor especifique o URL de início da página WAB. Para autenticação federada, esta etiqueta XML tem de existir.
Observação
O cliente de inscrição é agnóstico no que diz respeito aos fluxos de protocolo para autenticação e devolução do token de segurança. Embora o servidor possa pedir credenciais de utilizador diretamente ou introduzir um protocolo de federação com outro servidor e serviço de diretório, o cliente de inscrição é agnóstico a tudo isto. Para permanecer agnóstico, todos os fluxos de protocolo relativos à autenticação que envolvem o cliente de inscrição são passivos, ou seja, implementados no browser.
Seguem-se os requisitos explícitos para o servidor.
- O
<DiscoveryResponse>``<AuthenticationServiceUrl>elemento tem de suportar HTTPS. - O servidor de autenticação tem de utilizar um certificado de raiz fidedigna do dispositivo. Caso contrário, a chamada WAP falha.
- O WP não suporta a Autenticação Integrada do Windows (WIA) para o ADFS durante a autenticação WAB. ADFS 2012 R2, se utilizado, tem de ser configurado para não tentar WIA para dispositivo Windows.
O cliente de inscrição emite um pedido HTTPS da seguinte forma:
AuthenticationServiceUrl?appru=<appid>&login_hint=<User Principal Name>
-
<appid>é do formulárioms-app://string -
<User Principal Name>é o nome do utilizador que está a inscrever, por exemplo, user@constoso.com como entrada do utilizador numa página de início de sessão de inscrição. O valor deste atributo serve como uma sugestão que é utilizada pelo servidor de autenticação como parte da autenticação.
Após a conclusão da autenticação, o servidor de autenticação deve devolver um documento de formulário HTML com uma ação do método POST de appid identificada no parâmetro da cadeia de consulta.
Observação
Para tornar uma aplicação compatível com uma Política de Segurança de Conteúdo rigorosa, normalmente é necessário fazer algumas alterações aos modelos HTML e ao código do lado do cliente, adicionar o cabeçalho da política e testar se tudo funciona corretamente assim que a política for implementada.
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>
O servidor tem de enviar um POST para um URL de redirecionamento do formulário ms-app://string (o esquema de URL é ms-app), conforme indicado na ação do método POST. O valor do token de segurança é a cadeia http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary codificada com base64 contida no <wsse:BinarySecurityToken> atributo EncodingType. O Windows efetua o código binário quando o envia de volta para o servidor de inscrição, na forma de codificação HTML. Esta cadeia é opaca para o cliente de inscrição; o cliente não interpreta a cadeia.
O exemplo seguinte mostra uma resposta recebida do serviço Web de deteção que requer autenticação através da 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>
Serviço Web da política de inscrição
O serviço de política é opcional. Por predefinição, se não forem especificadas políticas, o comprimento mínimo da chave é 2k e o algoritmo hash é SHA-1.
Este serviço Web implementa a especificação X.509 Certificate Enrollment Policy Protocol (MS-XCEP) que permite personalizar a inscrição de certificados para corresponder às diferentes necessidades de segurança das empresas em momentos diferentes (agilidade criptográfica). O serviço processa a mensagem GetPolicies do cliente, autentica o cliente e devolve políticas de inscrição correspondentes na mensagem GetPoliciesResponse.
Para a política de autenticação federada, a credencial do token de segurança é fornecida numa mensagem de pedido com o <wsse:BinarySecurityToken> elemento [WSS]. O token de segurança é obtido conforme descrito na secção de resposta de deteção. As informações de autenticação são as seguintes:
- wsse:Security: o cliente de inscrição implementa o
<wsse:Security>elemento definido na secção 5 [WSS]. O<wsse:Security>elemento tem de ser subordinado do<s:Header>elemento . - wsse:BinarySecurityToken: o cliente de inscrição implementa o
<wsse:BinarySecurityToken>elemento definido na secção [WSS] 6.3. O<wsse:BinarySecurityToken>elemento tem de ser incluído como subordinado do<wsse:Security>elemento no cabeçalho SOAP.
Tal como foi descrito na secção de resposta de deteção, a inclusão do <wsse:BinarySecurityToken> elemento é opaca para o cliente de inscrição e o cliente não interpreta a cadeia e a inclusão do elemento é acordada pelo servidor de autenticação de tokens de segurança (conforme identificado no <AuthenticationServiceUrl> elemento de <DiscoveryResponse> e no servidor empresarial.
O <wsse:BinarySecurityToken> elemento contém uma cadeia codificada com base64. O cliente de inscrição utiliza o token de segurança recebido do servidor de autenticação e o base64-encodes o token para preencher o <wsse:BinarySecurityToken> elemento.
wsse:BinarySecurityToken/attributes/ValueType: o
<wsse:BinarySecurityToken>atributo ValueType tem de serhttp://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentUserToken.wsse:BinarySecurityToken/attributes/EncodingType: o
<wsse:BinarySecurityToken>atributo EncodingType tem de serhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd\#base64binary.
O exemplo seguinte é um pedido de política de inscrição com um token de segurança recebido 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>
Após a autenticação do utilizador, o serviço Web obtém o modelo de certificado que o utilizador deve inscrever e cria políticas de inscrição com base nas propriedades do modelo de certificado. Pode encontrar uma amostra da resposta no MSDN.
O MS-XCEP suporta políticas de inscrição flexíveis com vários Tipos e Atributos Complexos. Para o dispositivo Windows, iremos primeiro suportar o minimalKeyLength, as políticas hashAlgorithmOIDReference e os CryptoProviders. O hashAlgorithmOIDReference tem OID e OIDReferenceID relacionados e policySchema no GetPolicesResponse. O policySchema refere-se à versão do modelo de certificado. A versão 3 do MS-XCEP suporta algoritmos de hashing.
Observação
A resposta do servidor HTTP não pode definir Transfer-Encoding como Segmentado; tem de ser enviada como uma mensagem.
O fragmento seguinte mostra a resposta do serviço Web da política.
<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>
Serviço Web de inscrição
Este serviço Web implementa o protocolo MS-WSTEP. Processa a mensagem RequestSecurityToken (RST) do cliente, autentica o cliente, pede o certificado à AC e devolve-o no RequestSecurityTokenResponse (RSTR) ao cliente. Além do certificado emitido, a resposta também contém as configurações necessárias para aprovisionar o DMClient.
O RequestSecurityToken (RST) tem de ter a credencial de utilizador e um pedido de certificado. A credencial de utilizador num envelope SOAP RST é a mesma que em GetPolicies e pode variar consoante a política de autenticação seja OnPremise ou Federada. O BinarySecurityToken num corpo SOAP RST contém um pedido de certificado PKCS#10 codificado com Base64, que é gerado pelo cliente com base na política de inscrição. O cliente poderia ter pedido uma política de inscrição com MS-XCEP antes de pedir um certificado com MS-WSTEP. Se o pedido de certificado PKCS#10 for aceite pela autoridade de certificação (AC) (o comprimento da chave, algoritmo hash, etc., corresponder ao modelo de certificado), o cliente pode inscrever-se com êxito.
O RequestSecurityToken utiliza um TokenType personalizado (http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrollmentToken), porque o nosso token de inscrição é superior a um certificado X.509 v3. Para obter mais informações, consulte a secção Resposta.
O RST também pode especificar muitos itens AdditionalContext, como DeviceType e Version. Com base nestes valores, por exemplo, o serviço Web pode devolver a configuração de DM específica do dispositivo e específica da versão.
Observação
O serviço de política e o serviço de inscrição têm de estar no mesmo servidor; ou seja, têm de ter o mesmo nome de anfitrião.
O exemplo seguinte mostra o pedido do serviço Web de inscrição para autenticação 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>
Depois de validar o pedido, o serviço Web procura o modelo de certificado atribuído para o cliente, atualize-o se necessário, envia os pedidos PKCS#10 para a AC, processa a resposta da AC, constrói um formato XML de Aprovisionamento de Cliente OMA e devolve-o no RequestSecurityTokenResponse (RSTR).
Observação
A resposta do servidor HTTP não pode definir Transfer-Encoding como Segmentado; tem de ser enviada como uma mensagem.
Semelhante ao TokenType no RST, o RSTR utiliza um ValueType personalizado no BinarySecurityToken (http://schemas.microsoft.com/ConfigurationManager/Enrollment/DeviceEnrollmentProvisionDoc), porque o token é superior a um certificado X.509 v3.
O XML de aprovisionamento contém:
- Os certificados pedidos (obrigatório)
- A configuração DMClient (obrigatório)
O cliente instala o certificado de cliente, o certificado de raiz empresarial e o certificado de AC intermédia, se existir um. A configuração do DM inclui o nome e o endereço do servidor DM, que certificado de cliente utilizar, e agenda quando o DMClient chama de volta para o servidor.
O XML de aprovisionamento de inscrição deve conter um máximo de um certificado de raiz e um certificado de AC intermédio que é necessário para encadear o certificado de cliente MDM. Podem ser aprovisionados mais certificados de AC intermédia e raiz durante uma sessão de DM OMA.
Quando os certificados de AC intermédia e de raiz estão a ser aprovisionados, o caminho do nó CSP suportado é: CertificateStore/Root/System para o aprovisionamento de certificados de raiz, CertificateStore/My/User para o aprovisionamento de certificados da AC intermédia.
Eis uma mensagem RSTR de exemplo e um exemplo de XML de aprovisionamento de cliente OMA no RSTR. Para obter mais informações sobre os fornecedores de serviços de configuração (CSPs) utilizados no aprovisionamento de XML, veja a secção Definições, políticas e gestão de aplicações empresariais.
O exemplo seguinte mostra a resposta do serviço Web de inscrição.
<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>
O código seguinte mostra o XML de aprovisionamento de exemplo (apresentado no pacote anterior como um token de segurança):
<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>
Observação
<Parm name>e<characteristic type=>os elementos no XML CSP da Aplicação w7 são sensíveis às maiúsculas e minúsculas e têm de estar todos em maiúsculas.Na característica da aplicação w7, as credenciais CLIENT e APPSRV devem ser fornecidas em XML.
As descrições detalhadas destas definições estão localizadas na secção Definições, políticas e gestão de aplicações empresariais deste documento.
A característica PrivateKeyContainer é necessária e tem de estar presente no XML de aprovisionamento de inscrição pela inscrição. Outras definições importantes são os elementos de parâmetro PROVIDER-ID, NAME e ADDR , que têm de conter o ID exclusivo e o NOME do seu fornecedor de DM e o endereço onde o dispositivo se pode ligar para o aprovisionamento de configuração. O ID e o NOME podem ser valores arbitrários, mas têm de ser exclusivos.
Também importante é SSLCLIENTCERTSEARCHCRITERIA, que é utilizado para selecionar o certificado a ser utilizado para autenticação de cliente. A pesquisa baseia-se no atributo subject do certificado de utilizador assinado.
O CertificateStore/WSTEP permite a renovação do certificado. Se o servidor não o suportar, não o defina.