Date post: | 28-May-2015 |
Category: |
Technology |
Upload: | cloudidsummit |
View: | 145 times |
Download: | 0 times |
Disclaimer Chances of me being misguided or even outright wrong with following statements are higher than average (my average, not Ashish's).
1
BYOD is (merely) an ownership model,
doesn’t significantly change the
fundamentals.
2
no
Is device choice constrained?
enterprise Who owns device
yes
BYOD
employee
COPE
CYOD
mass resigna@ons
of IT personnel
IT'S NOT ABOUT THE DEVICE
It's the data
MDM
MAM
MIM
Personal app
Business app
Enterprise control
Device
Premise
• Depending on context, IT will impose differen@ated controls – Use camera – Take screenshot – Wifi – Email account to use
• MDM, MAM, & MIM differ in the granularity of the context they account for
Contexts • Who is the user?
– controls based on employee iden@ty & roles, e.g. IT admin vs Sales Director
• What are they doing? – controls based on what applica@on the employee is using, eg viewing
a spreadsheet • Why are they doing it?
– controls based on whether the employee is ac@ng in a business or personal persona, eg viewing financial projec@ons vs hockey team stats
• Where are they doing it? – controls based on geoloca@on, e.g. in office vs on business trip – controls based on device, e.g. on iPad vs Blackberry
• When are they doing it? – controls based on @me etc, e.g. office hours vs weekend or last @me
user signed in
MDM
• In MDM, the context is the device, ie policy looks like – "If you are using this device, then you cannot use public wifi'
• Coarse granularity implies that the enterprise imposed limita@ons will impact non business use of device
personal
Device usage
enterprise Device owner
enterprise
None of your business
employee
Your business
MAM
• In MAM, the context is the applica@on being used, ie policy looks like – "If you are using the enterprise Box applica@on, you cannot store data on the device'
• Medium granularity implies that there will need to be mul@ple versions of some applica@ons, those that the user wants for both personas
All apps
Those that are MAM-enabled
Those enabled to work with your preferred MAM
Those your employees want to use
Sweet spot
MIM
• In MIM, the context is determined by the informa@on – enterprise data carries with itself the policy, ie looks like – "When viewing/edi@ng this spreadsheet, you cannot use the screenshot func@on'
• A single applica@on could work with both personal & enterprise data (if MIM enabled)
Balancing Act
Security
Privacy Enablement
Standards
15
Pick any one
Privacy?
the right to be let alone—the most comprehensive of rights and the
right most valued by
civilized menLouis Dembitz Brandeis
17
Separa@on
18
Dual Persona in MDM
Dual Persona in MAM Dual Persona in MIM
Dual persona is by defini@on an iden1ty concept.
20
21
Extremely over simplified mobile security model
1. Ensure that user/app can access only appropriate apps/data
2. Protect data in transit 3. Protect data on device 4. When necessary, turn off access
Mechanisms? 1. Ensure that user/
app can access only appropriate apps/data
2. Protect data in transit
3. Protect data on device
4. When necessary, turn off access
• Server-based access control as per groups/roles • Inter-app controls (eg Managed Open In etc)
• Stop issuing tokens • Revoke any extant tokens • Wipe data (or keys)
• Hardware level encryption • Application level encryption
• SSL or VPN etc • Secure SDKs, custom URL schemes
EMM in a nutshell
Business Applica@on
Business Data
EMM server endpoints
Agent
Con
figur
atio
n
Cre
dent
ials
Pol
icy
Dire
ctiv
es
Business Data
Generic lifecycle 0. Provision accounts 1. Install app (OPT?) 2. Ini@al user authen@ca@on 3. Bind to Server 4. Download policy & addi@onal creden@als 5. Use creden@als to access applica@ons 6. Ongoing management
SCIM
SAML
OAuth
OIDC
Iden@ty standards & EMM
27
EMM Apps Apps Apps
Directory SCIM
SCIM
SAML OpenID Connect
OAuth
SCIM
• Simple Cloud Iden@ty Management (or System Cross Domain Iden@ty Management)
• RESTful protocol for user provisioning, ie create, read, updates, deletes
• Emerged from large SaaS providers & ISVs • Under IETF standardiza@on
28
Iden@ty standards & EMM
29
EMM Apps Apps Apps
Directory SCIM
SCIM
SAML
• Security Asser@on Markup Language • XMl-‐based framework for making security & iden@ty informa@on portable across domains
• Architypical applica@on is for Web SSO • Default SSO protocol for B2B, SaaS • Google, Salesforce, WebEx, etc
30
OAuth
• Open framework for authoriza@on & authen@ca@on for REST APIs
• Emerged from consumer web, transi@oning into cloud & enterprise
• Notable for its mobile op@miza@ons (rela@ve to precedents)
• IETF standardized • Important plagorm for other standards, UMA etc
31
Iden@ty standards & EMM
32
EMM Apps Apps Apps
Directory
SAML
OAuth
Enterprise EMM provider
Browser EMM Agent
1
2 3
4
1) EMM Agent loads EMM provider authn page
2) EMM provider does SAML SSO to enterprise
3) After SAML SSO, EMM provider issues OAuth access token to agent
4) EMM Agent uses access token to pull policy etc down
5) EMM provider returns policies etc 5
Leverage EMM provisioned creds
OpenID Connect
• Profiles/extends OAuth for iden@ty use cases • Under standardiza@on in OIDF • Defines new
– Id_token – standardized token format for iden@ty, enables Web SSO
– UserInfo endpoint – standardized API for airibute sharing
34
Iden@ty standards & EMM
35
EMM Apps Apps Apps
Directory
OpenID Connect
Device
Na@ve SSO?
Browser
Resource Server
App client
Resource Server
App client EMM Agent
EMM Server
Authoriza@on Server
2��
Policy & Token
s
1��
3��
API
API
4��
Wrapping up
• Separa@on (whatever the mechanism & the UX) between work & personal usages promises balance of security, privacy, enablement etc
• Dual persona is by its nature an iden@ty concept
• Iden@ty standards have a role to play in enabling dual persona
• Lets keep conversa@on going
37