×
Namespaces

Variants
Actions
(Difference between revisions)

Archived:Establishing trust between OMA DM server and a Symbian device

From Nokia Developer Wiki
Jump to: navigation, search
hamishwillee (Talk | contribs)
m (Hamishwillee - Automated change of text from Forum Nokia to Nokia Developer. (Rebrand))
hamishwillee (Talk | contribs)
m (Hamishwillee - Bot update - Fix links)
 
(5 intermediate revisions by 2 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{Archived|timestamp=20120223112842|user=roy.debjit| }}
__NOEDITSECTION__
+
[[Category:Symbian C++]][[Category:S60 3rd Edition FP1]][[Category:Device Management]]
{{KBTS}}
+
{{ArticleMetaData <!-- v1.2 -->
{{KnowledgeBase
+
|sourcecode= [[Media:Certificate mapping.zip]] [[Media:Roles mapping.zip]]
|id=TSS001360
+
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
|platform=S60 3rd Edition FP1, S60 3rd Edition, FP2
+
 
|devices= Eseries devices
 
|devices= Eseries devices
|category=Symbian C++
+
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Nokia Qt SDK 1.1]) -->
|subcategory=OMA DM
+
|platform= S60 3rd Edition FP1, S60 3rd Edition, FP2
|creationdate=May 12, 2009
+
|devicecompatability= <!-- Compatible devices (e.g.: All* (must have GPS) ) -->
|keywords=  
+
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Empty or one of Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20090512
 +
|author= [[User:Technical writer 1]]
 +
<!-- The following are not in current metadata -->
 +
|subcategory= OMA DM
 +
|id= TSS001360
 
}}
 
}}
 
 
== Description ==
 
== Description ==
  
Line 24: Line 38:
 
First, the certificate mapping policy is sent.
 
First, the certificate mapping policy is sent.
 
   
 
   
[[Image:Certificate_mapping.zip]]
+
[[File:Certificate mapping.zip]]
  
The above policy creates a mapping between the certificate and the <tt>alias_id</tt>. The policy does not create the trust but simply describes that <tt>COMCOM</tt> is the "short name"/alias for the given certificate.
+
The above policy creates a mapping between the certificate and the {{Icode|alias_id}}. The policy does not create the trust but simply describes that {{Icode|COMCOM}} is the "short name"/alias for the given certificate.
  
 
After this, the roles mapping policy is sent.
 
After this, the roles mapping policy is sent.
  
[[Image:Roles_mapping.zip]]
+
[[File:Roles mapping.zip]]
  
The above policy maps the <tt>COMCOM</tt> role to be the <tt>trustedadmin</tt> which is the <tt>role_id</tt> of the <tt>COMCOM</tt>. This policy will display the device security indicator § in the status pane.
+
The above policy maps the {{Icode|COMCOM}} role to be the {{Icode|trustedadmin}} which is the {{Icode|role_id}} of the {{Icode|COMCOM}}. This policy will display the device security indicator § in the status pane.
  
  
Line 39: Line 53:
 
In this approach, both the certificate and role mappings are done at the same time with a single policy:
 
In this approach, both the certificate and role mappings are done at the same time with a single policy:
  
[[Image:Certificate_roles_mapping.txt]]
+
[[File:Certificate roles mapping.txt]]
  
The command: <tt>use_bearer_certificate = "true"</tt> will cause the certificate to be searched directly from the HTTPS session. In Approach 1, the certificate is taken from the policy file itself.
+
The command: {{Icode|use_bearer_certificate = "true"}} will cause the certificate to be searched directly from the HTTPS session. In Approach 1, the certificate is taken from the policy file itself.
  
 
The second approach is an easy way to establish trust as both certificate mapping and roles mapping are handled automatically.
 
The second approach is an easy way to establish trust as both certificate mapping and roles mapping are handled automatically.
Line 47: Line 61:
 
==See also==
 
==See also==
 
[http://www.developer.nokia.com/info/sw.nokia.com/id/2ff7409a-cbb3-4151-bbae-247aac7cda33/OMA_Device_Management_DDF_for_Policy_Management_v1_1_en.zip.html OMA Device Management DDF for Policy Management]
 
[http://www.developer.nokia.com/info/sw.nokia.com/id/2ff7409a-cbb3-4151-bbae-247aac7cda33/OMA_Device_Management_DDF_for_Policy_Management_v1_1_en.zip.html OMA Device Management DDF for Policy Management]
 
+
[[Category:Code Examples]]
[[Category:Symbian C++]][[Category:S60 3rd Edition FP1]][[Category:Technical Solution]][[Category:Device Management]]
+

Latest revision as of 08:23, 29 June 2012

Archived.pngArchived: This article is archived because it is not considered relevant for third-party developers creating commercial solutions today. If you think this article is still relevant, let us know by adding the template {{ReviewForRemovalFromArchive|user=~~~~|write your reason here}}.

Article Metadata
Code ExampleTested with
Devices(s): Eseries devices
Compatibility
Platform(s): S60 3rd Edition FP1, S60 3rd Edition, FP2
S60 3rd Edition FP1
Article
Created: User:Technical writer 1 (12 May 2009)
Last edited: hamishwillee (29 Jun 2012)

Contents

[edit] Description

Establishing trust between a device and the DM server is described in OMA Device Management DDF for Policy Management available at Nokia Developer. This article explains the possible ways of establishing trust and the different policies that can be used.

[edit] Solution

There are two ways to create corporate trust.

[edit] Separate mapping for certificate and roles

First, the certificate mapping policy is sent.

File:Certificate mapping.zip

The above policy creates a mapping between the certificate and the alias_id. The policy does not create the trust but simply describes that COMCOM is the "short name"/alias for the given certificate.

After this, the roles mapping policy is sent.

File:Roles mapping.zip

The above policy maps the COMCOM role to be the trustedadmin which is the role_id of the COMCOM. This policy will display the device security indicator § in the status pane.


[edit] Alternative approach

In this approach, both the certificate and role mappings are done at the same time with a single policy:

File:Certificate roles mapping.txt

The command: {{{1}}} will cause the certificate to be searched directly from the HTTPS session. In Approach 1, the certificate is taken from the policy file itself.

The second approach is an easy way to establish trust as both certificate mapping and roles mapping are handled automatically.

[edit] See also

OMA Device Management DDF for Policy Management

This page was last modified on 29 June 2012, at 08:23.
82 page views in the last 30 days.
×