Hi, I have to re implement the syncml engine to continue syncml message flow,because after completed the certificate process,Windows phone initially starts syncml message flow.
*Syncml*The OMA Device Management Protocol allows management commands to be executed on nodes. It uses a package format similar to SyncML Synchronization Protocol [SYNCPRO] and SyncML Representation Protocol [REPPRO].Each node MUST be addressed by a unique full device URI. URIs MUST follow requirements specified in UniformResource Identifiers (URI) [RFC2396] with the restrictions as specified in OMA Device Management Tree and Descriptions.In OMA DM Protocol, the target and source of a command are identified by the Target and Source elements respectively. Target refers to the recipient, and Source refers to the originator. SyncML Components: • SyncML is a specification that contains the following main components: • An XML-based representation protocol • A synchronization protocol and a device management protocol • Transport bindings for the protocol *Syncml Message format* <SyncML> <SyncHdr> <VerDTD>1.1</VerDTD> <VerProto>SyncML/1.1</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target><LocURI>IMEI:493005100592800</LocURI></Target> <Source><LocURI>http://www.syncml.org/sync-server</LocURI></Source> </SyncHdr> <SyncBody> -------------------------------------------------------------------- </SyncBody> </SyncML> The document consists of a header, specified by the SyncHdr element type, and a body, specified by the SyncBody element type. The SyncML header specifies routing and versioning information about the SyncML Message. The SyncML body is a container for one or more SyncML Commands. The SyncML Commands are specified by individual element types. The SyncML Commands act as containers for other element types that describe the specifics of the SyncML command, including any data or meta-information. *Security-Syncml* An objective of SyncML is to provide a framework for secure operation. SyncML itself does not define any new security schemes. Instead, it provides the framework to challenge authentication, authentication, authorization and inclusion of encrypted data in a SyncML Package. In addition, the originator and recipient MAY use the security mechanisms of the underlying transport to authenticate each other and to provide a secure transport for the exchange of SyncML Packages. SyncML can be used by an originator to encapsulate authentication information in the Cred element type. *Authorization* The Cred element MUST be included in requests (message or command)which are sent after receiving the 401 or 407 responses if the request is repeated. In addition, it can be sent in the first request from a device if the authentication is mandated through pre-configuration. The content of the Cred element is specified in [DMREPPRO]. The authentication type is dependent on the challenge. *Application layer authentication* The authentication on the application layer is accomplished by using the Cred element in SyncHdr and the Status command associated with SyncHdr. Within the Status command, the challenge for the authentication is carried as defined earlier. The authentication can happen both directions, i.e., the client can authenticate itself to the server and the server can authenticate itself to the client. Example User (Device)send initial request without credentials <SyncML xmlns='SYNCML:SYNCML1.2'> <SyncHdr> <VerDTD>1.2</VerDTD> <VerProto>DM/1.2</VerProto> <SessionID>1</SessionID> <MsgID>1</MsgID> <Target><LocURI>http://www.syncml.org/mgmt-server</LocURI></Target> <Source><LocURI>IMEI:493005100592800</LocURI></Source> </SyncHdr> <SyncBody> ... </SyncBody> </SyncML> The server challenges the client for the application layer authentication. The client MUST send again with the credentials. The server accepts the credentials and the session is authenticated.Normally reciver or originator response each other with the status tag for the privious message.needs to send status for each command that request from the receipiant and also need to send status for syncml header element.In here as client does not provide <Cred> information in the <SyncHdr>,Server must send 407 status for the Header with challenge. <SyncML xmlns='SYNCML:SYNCML1.2'> <SyncHdr> <VerDTD>1.2</VerDTD> <VerProto>DM/1.2</VerProto> <SessionID>1</SessionID> <MsgID>1</MsgID> <Target><LocURI>IMEI:493005100592800</LocURI></Target> <Source><LocURI>http://www.syncml.org/mgmt-server</LocURI></Source> </SyncHdr> <SyncBody> <Status> <CmdID>1</CmdID> <MsgRef>1</MsgRef> <CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <TargetRef>http://www.syncml.org/mgmt-server</TargetRef> <SourceRef>IMEI:493005100592800</SourceRef> <Chal> <Meta> <Type xmlns=’syncml:metinf’>syncml:auth-basic</Type> <Format xmlns=’syncml:metinf’>b64</Format> </Meta> </Chal> <Data>407</Data> <!-- Credentials missing --> </Status> ... </SyncBody> </SyncML> Then client send syncml message with cred tag. <SyncML xmlns='SYNCML:SYNCML1.2'> <SyncHdr> <VerDTD>1.2</VerDTD> <VerProto>DM/1.2</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target><LocURI>http://www.syncml.org/mgmt-server</LocURI></Target> <Source><LocURI>IMEI:493005100592800</LocURI></Source> <Cred> <Meta> <Type xmlns=’syncml:metinf’>syncml:auth-basic</Type> <Format xmlns='syncml:metinf'>b64</Format> </Meta> <Data>QnJ1Y2UyOk9oQmVoYXZl</Data> <!-- base64 formatting of “userid:password” --> </Cred> </SyncHdr> <SyncBody> ... </SyncBody> </SyncML> Now server can authenticate user by using md5 hash which is in the data tag. Note:That value is generate from the device by using response security token which is provided with in the MS-WSTEP. Server response <SyncML xmlns='SYNCML:SYNCML1.2'> <SyncHdr> <VerDTD>1.2</VerDTD> <VerProto>DM/1.2</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target><LocURI>IMEI:493005100592800</LocURI></Target> <Source><LocURI>http://www.syncml.org/mgmt-server</LocURI></Source> </SyncHdr> <SyncBody> <Status> <CmdID>1</CmdID> <MsgRef>2</MsgRef> <CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <TargetRef>http://www.syncml.org/mgmt-server</TargetRef> <SourceRef>IMEI:493005100592800</SourceRef> <Data>212</Data> <!-- Authenticated for session --> </Status> ... </SyncBody> </SyncML> In windows scenario,After this initial authentication completed,device send next message with challenge tag.It contains nonce. *Client request* <SyncBody> <Status> <CmdID>1</CmdID> <MsgRef>1</MsgRef> <CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <Chal> <Meta> <Format xmlns="syncml:metinf">b64</Format> <Type xmlns="syncml:metinf">syncml:auth-md5</Type> <NextNonce xmlns="syncml:metinf">8mbuo826FKbvgnASnKnkSGhTQa4tlnuE9pYW1LDEbEc=</NextNonce> </Meta> </Chal> <Data>212</Data> </Status> .............. <SyncBody> Server Responce On Tue, Aug 11, 2015 at 1:55 PM, Hasunie Adikari <hasu...@wso2.com> wrote: > Hi all, > I have already developed windows phone enrollment process as my fast track > training project.and now I have to implement phone management client part > which periodically synchronizes with the management server to check for > updates and apply the latest policies set by IT.and push notification > service.Below I briefly describe the project. > > *Description* > > Windows phone’s built in management component can communicate with > Management Server.There are two parts to the Windows Phone 8.1 management > component: > > - > > The enrollment client, which enrolls and configures the phone to > communicate with the enterprise management server. > > > > - > > The phone management client, which periodically synchronizes with the > management server to check for updates and apply the latest policies set by > IT.and push notification service. > > > *Enrollment Client* > Overview of the windows mobile device enrollment process. > *Windows phone -*there is company App(Workplace) > *Proxy* -apache2 server configure as a Proxy server > *WAB * -Web Authentication Broker,Windows Phone 8.1 adds > the support of a Federated as supported AuthPolicy value. When > authentication policy is set to be Federated, Web Authentication Broker > (WAB) will be leveraged by the enrollment client > to get a security token. > *MDM* -Mobile device management third party server. > > > [image: MyWindows Phone.png] > * Requirement Task* > 1.Configure the device Environment so that device can securely > communicate with Mobile management server. > 2.Provide Configurable Service and policy end points from the > Discovery web service. > 3.Generate binary security token value for the specific user and > persist. > 4.Persist Device Information and Enroll Device > *Sub task* 4.1 :Handle WSTEP endpoint's Client response > message > 4.2 :Check the syncml message comes from the > device as a response > 4.3 :Use Syncml engine for generate syncml > payloads and parse them. > 4.4 :Authenticate Syncml Messages. > > > *Requirement Task 1:* > Configure Apache2 as a Proxy server. > *Problem:* > > - Proxy configurations are changed according to the apache server > version and operating system. > - Rewrite engine rules and reverse proxy rules are invoked in > separately. > - Apache2 SSL configurations are essential for the discovery end point. > > *Solution:* > Detail description about the configuration.Click here > <https://docs.google.com/document/d/1es2U5BPjmxWhjYw5ekULpkMCYS_TWf_FIPhyCsDdBJ4/edit> > > * Requirement Task 2:* > *Problem* > Mobile device client get the Enrollment policy URL and Enrollment > service URL from the Discovery service(above no4 line in the diagram).The > automatic discovery service constructs a URI that uses this host name by > appending the sub domain > “EnterpriseEnrollment” to the domain of the email address, and by > appending the path “/EnrollmentServer/Discovery.svc”. For example, if the > email address is “ad...@wso2.com”, the resulting URI for first Get > request would be: > > https://EnterpriseEnrollment.wso2.com/EnrollmentServer/Discovery.svc > *Solution* > Add (domain) child element to the windows plugin properties.xml > file.Servletcontext listener initialize the domain value and set the > specific value as a servlet context attribute.Discovery service get the > domain of the Email using servlet context attribute. > > *Requirement Task 3:* > *Problem* > The opaque security token that is returned from WAB(Web > authentication leverage) as an endpage will be used by the enrollment > client as the device security secret during the client certificate > enrollment request call.Enrollment policy endpoint needs to > provide policy template after authenticate the user by credentials > and also Enrollment service end point needs to authenticate using same > binary security token. > > *Solution* > AuthBST service endpoint generate binary security token for the > user using UUID java class.The UUID is generated using a cryptographically > strong pseudo random number generator.That 128 bit value persist in cache > as it is temporary token for > enrollment. > Cache Entry: binary security token(Key)|device > identifier,UserName(Cache Entry value) > > * Enrollment Process Detail* in XCEP > The security token credential is provided in a SOAP request message > header in XCEP for get policy template. > just after coming to the XCEP, CXF validator class extract the soap > header values and authenticate Binary security token with the persist token. > > *Requirement Task 4*: > Sub Task 4.1: > *WSTEP Detail*: MS-WSTEP(WS-Trust X.509v3 Token Enrollment > Extensions) process the request security token from the the > client.Certificate sign request (CSR) is provided according to the XCEP > policy template.Service get the request and update it > if needed, sends the PKCS#10 requests to the CA, processes the > response from the CA,constructs an OMA Client Provisioning XML format, and > returns it in the RequestSecurityTokenResponse(RSTR) > > *Authenticate user request* > WSTEP,SOAP header contains Binary security token as above XCEP > request.At that point I used apache cfx method to read SOAP > header.Resultant Apache.cfx.Header type object list contains the Header xml > child elements.It will easier to extract > child element binary security token under parent security by using > DOM parser.Then authenticate user request. > > *Create Bootstrap XML file* > OMA DM(Object Mobile alliance Device Management) specifications > define how a management session is established and maintained. However, in > order for a device to be able to initiate a management session it must be > provisioned with OMA DM > settings. Bootstrap is a process of provisioning the DM client to a > state where it is able to initiate a management session to a new DM server. > Bootstrap can move a device from an un-provisioned, empty state, to a state > where it is able to initiate a > management session to a DM server. DM clients that have already been > bootstrapped can be further bootstrapped to enable the device to initiate a > management session to new DM servers. > > the xml file should contain Root certificate,User Signed > certificate,Device manager client configurations and An enterprise > application token and an enterprise app download link to allow the > enrollment client to download a Company Hub or enterprise app > at the end of enrollment.Last information is optional.Both Device > and Server must be authenticated.Those credentials are configured in the > Bootstrap file. > > Sub Task 4.2: > *Syncml protocol*: An XML-based representation protocol which is for > data synchronization and device management.This link provide more details > about the syncml.Click here > <http://wacha.ch/wiki/_media/projects:syncml_sync_protocol_v11_20020215.pdf> > > After completed the WSTEP,device send initial Syncml message to the > syncml service endpoint which is provided in the bootstrap xml.There are > two parts in the syncml message.SyncHeader and syncBody.First initial > syncml message contains client’s > credentials in the CRED tag in the SyncHeader. > example: > <Cred> > > <Meta> > > <Format xmlns="syncml:metinf">b64</Format> > > <Type xmlns="syncml:metinf">syncml:auth-md5</Type> > > </Meta> > > <Data>Fy80ofqnfKLFLWD+rzm9tQ==</Data> > > </Cred> > > > Search Note : CRED data tag > According to the OMA DM Security specification.The digest supplied in > the Cred element is computed as follows: > Let H = the MD5 Hashing function. > Let Digest = the output of the MD5 Hashing function. > Let B64 = the base64 encoding function. > Digest = H(B64(H(username:password)):nonce) > these data is related with the client credentials of the bootstrap > xml.Then MDM server syncml service endpoint authenticate Device > request.Task 3 also completed by identifying specific user from persist > data. > > > Sub Task:4.3: > Re implement the syncml engine according to the syncml message chain. > > > > Sub Task 4.4:authenticate device client using cred data which is > calculated by using client credentials in the bootstrap xml file.MDM server > respond to the device using server credentials in the Bootstrap xml file. > > > For more details Click here > <https://docs.google.com/document/d/1tyI2K_uzMq8cvrU8OhReRXKYg2fr0hEVqgm437nYt6E/edit> > > > > > > > > > > > > > > > > > -- > *Hasunie Adikari* > Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > blog http://hasuniea.blogspot.com > Mobile:+94715139495 > -- *Hasunie Adikari* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware blog http://hasuniea.blogspot.com Mobile:+94715139495
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
