Derived credentials: Choosing the right solution
White Paper
Derived credentials: Choosing the right solution
White Paper
Table of contents
Executive summary
Executive summary
2
Derived credentials and digital IDs
2
Holistic digital approach
2
The challenges
3
Derived credential considerations
3
Strategic approach
6
Derived credential integration options
7
Credential management considerations
7
Conclusion
8
About the author
8
Mobility is rapidly evolving—with each device release, operating system (OS) release, new security issue, Enterprise Mobility Management (EMM) evolution, and productivity solution. Enterprises are embracing mobility and responding to user demands for productive mobile solutions. Users want their device, applications (apps), and network access to just work—without numerous passwords or card readers. Enterprises want secure interactions and centralized control, while maximizing productivity without data loss. Digital IDs or derived credentials help enable these mission and user demands. Derived credentials are driven by the user experience, increased adoption, productivity, and security. With digital ecosystems, you need a holistic view of mobility, security, identity and access management, credential management, and use cases to make decisions for derived credential solutions. This paper discusses considerations that help you choose the right derived credential solution for your enterprise. Derived credentials and digital IDs The National Institutes of Standards and Technology (NIST) defines the derived credential as: “A credential issued based on proof of possession and control of a token associated with a previously issued credential, so as not to duplicate the identity proofing process.” In the federal government, these credentials are derived from a common access card (CAC) or a personal identity verification (PIV) card. They can be used for mobile application authentication, encryption, and signing with a derived credential placed on the mobile device per the federal CAC/PIV model covered by NIST 800-157. Derived credentials are special-case digital IDs generated from a CAC or PIV card. They are created using a credential chain to a certificate authority and placed on a mobile device. A digital ID can be any form of ID or rights-management credential. Examples include a driver’s license or the digital equivalent of any state or local ID. Digital IDs for financial access can be placed on mobile devices, enabling financial transactions similar to Apple Pay or Google Wallet. In addition, digital IDs can be created for insurance cards and entitlement rights or to represent other identifiers. The primary uses for derived credentials include network and computer systems login, digital signatures and encrypted email, secure browsing, application access, enterprise artifacts access, and controlled physical access. Holistic digital approach The motivation for derived credentials include eliminating card readers, increasing user adoption, mobility, mission value, new risk mitigation methods, and reducing costs. Using derived credentials is a user experience and cost-reduction discussion encompassing security requirements and especially preventing data loss. A derived credential on a smartphone combines something you have and something you know in a device you use every day. These motivations let you use derived credentials placed on a mobile device as you would a traditional physical card credential, and it offers new ways to combine technologies not possible before.
2
White Paper
In traditional credential management, once a user is sponsored, enrolled, and adjudicated, a card or token is issued and activated. Then enrollment and issuance processes are complete, giving users access. Placing a derived credential on a mobile device is just the beginning. Depending on the use cases and security requirements, where and how the derived credential is placed on the device impacts the enterprise’s ability to realize full value and satisfy its needs. Without holistic digital considerations, use cases are limited, and data loss is possible, even with a derived credential conforming to NIST Office of Management and Budget level of assurance (LOA) 4 (very high assurance level). The challenges Mobility has unique manifestations based on enterprise and user requirements and experiences. There are three general mobility methods enterprises can employ to govern data access. The first method provides a fully locked-down device to the employee, where an enterprise mobility management (EMM) solution is not necessarily installed. However, security measures, for example, placing a hardened Android image on the device or limiting access to certain locations or access points are in the policy. VPNs are also used in this method, which is the least flexible and requires commonly overlooked support infrastructure and costs. The second method uses a browser-based approach. The commercially available device accesses information via a browser, secure browser, or mobile web application. In this method, no enterprise data is stored on the device. However, user experience is governed by specific network access and bandwidth. To enforce this method, an EMM may be provisioned to prevent data loss. The last method comprises placing an EMM on the commercially available device that gives the enterprise device management, application, and policy enforcement control over the device or more importantly, control over the enterprise data. Figure 1. Derived credential evaluation flow
Derived credential considerations Four aspects must be evaluated, including: • Mission goals, drivers, and use cases • Security protecting mission data • Device policy • Integrations 3
White Paper
Mission Mobility security and derived credentials must be considered along with mission goals, drivers, and use cases because of solution dependencies. Otherwise, erroneous outcomes are probable, such as unintended data loss, not being able to use mobile apps as expected, mobility management issues and failures, and a poor user experience resulting in lower adoption. Security In addition to the derived credentials, you must evaluate data protection, including the level of data-loss risk you can tolerate based on derived credential compromise, device compromise, lost or stolen device, and data loss from user actions (for example, copy-sensitive email or document data) on the device. These answers drive whether an EMM solution is required, if a hardened OS is required, and where the derived credential is stored on the device. Storage location Storage location directly impacts the NIST LOA, which addresses derived credential tampering and other risks. See Table 1. Control over the derived credential storage location is governed by one or more of the following: • Device manufacturer • Operating system • Identity credential access management (ICAM) solution • EMM solution
4
White Paper
Table 1. Derived credential storage options
Device Using results from mission and security analysis, you must choose the method to procuring, deploying, and enabling device connectivity to your enterprise. Policies to consider include: • Bring your own device (BYOD) or organization-provided devices • NIST LOA requirements • Enterprise hardened OS devices • Secure devices • Enterprise-required mobile devices with Windows, iOS, Android, or BlackBerry • Enterprise mobility management integration with laptops, desktops, or workstations These considerations determine which device management is required. Integration Most enterprises use an EMM solution to manage their enterprise-issued mobile devices and BYODs for policy enforcement, enterprise data access, security augmentation, and data loss prevention (DLP).
5
White Paper
EMM systems are used to manage specific enterprise apps, which often require derived credential authentication, encryption, or signing. In this analysis, use cases and security must be kept in the forefront. It’s possible to adopt a derived credential solution that doesn’t prevent data loss or conflict with your EMM solution. For this reason, the ICAM–EMM integration strategy requires evaluation. Consider, for example, if your organization will use the same or different ICAM solution for all sub entities. Also consider if an EMM solution will be used throughout the enterprise, if at all, or will other EMMs be used for the sub entities within the organization. These issues will determine if an ICAM–EMM integration is necessary and specifically how the ICAM–EMM solutions are integrated. Keep in mind these integrations directly impact the mobile app usability, data loss prevention, and user experience. For example, if a mobile application is used across the enterprise with sub entities using different EMMs or different ICAMs, then you must decide which ICAM, EMM, or middleware software development kit (SDK) to use for application-derived credential access. To further understand the potential integration limitations between ICAM and EMM solutions, we need to understand basic EMM function, current ICAM derived credential solutions, and potential mobile application impacts. EMM functionality Most EMMs provide a secure encrypted container on the device as a repository for enterprise apps and customized secure apps for email and browsing; all are used to prevent data loss. The container encapsulates enterprise interests from personal interests on the device. This container requires authentication for access per established enterprise policy. It can authenticate, using the derived credential. In addition to container authentication, enterprise mobile apps may require authentication, signing, and encryption using the derived credential. The EMM enforces enterprise policies and prevents using native OS apps for enterprise email and browsing because there is no enforcement, monitoring, or control over them. Outside the EMM, container enterprise data and applications are inaccessible by native apps. ICAM derived credential solutions Looking at current derived credential ICAM solutions, ICAM vendors develop an encapsulated derived credential application. In addition, the ICAM vendor solution provides secure email and secure browsing mobile apps that work with the ICAMderived credential app. This approach, however, has challenges as the ICAM email and browsing apps may conflict with those provided by the EMM already installed on the device. The ICAM apps may not be subject to enterprise policy enforcement using the EMM. The EMM typically does not have access to the ICAM derived credential app without a tight direct integration using an ICAM provided SDK. It also means that enterprise mobile applications don’t have access to the ICAMderived credential controlled by the vendor derived credential app unless they are developed with the ICAM SDK. For most enterprises, this means a derived credential management system or ICAM solution must integrate with the EMM solution to support usable derived credentials on the device. 6
White Paper
ICAM–EMM integration mobile application considerations Tight, direct integrations are prevalent between ICAM and EMM solutions to resolve joint use of derived credentials. Current approaches are tactical; see Figure 2. With integrations that are custom and specific to each specific ICAM/EMM vendor pair involved, a proprietary SDK is often required for mobile apps. Each line in Figure 2 represents an integration that would potentially use a unique application SDK under the current approach. Using this tactical approach, apps are compiled specific to the customer ICAM/EMM environment pair’s SDK, causing potential for future unforeseen application development costs, application signing challenges, and environment inflexibility.
Figure 2. Undesirable tactical integrations
For a more simplistic approach, app developers want one app to be signed and distributed to the iTunes, Play Store, Windows, or enterprise app store. They want to eliminate the need to recompile an app targeted for a specific OS for each specific ICAM/EMM environment pair using a related SDK. With this ICAM/EMM tactical integration paradigm, if the enterprise has different departments or groups that use different ICAM/EMM environment pairs, then mobile app instantiation is necessary for each ICAM/EMM pair using the pertinent SDK. See Figure 3. This is an undesirable scenario, specifically, because it becomes an enterprise and lifecycle management problem, as well as an application development issue. It’s an enterprise problem because there may be unexpected future events when an ICAM or EMM solution needs to change. It’s a lifecycle management problem for tracking which instantiated app is used by which ICAM/ EMM environment. It’s an application development issue because it requires multiple versions of the same app for each ICAM/EMM pair. Following is an approach to address this challenge.
7
White Paper
Figure 3. One application requires unique changes for each ICAM/EMM pair for the same OS target
Strategic approach If you have multiple sub entities with different EMMs that require the same mobility app, you need a strategic approach to maximize benefits from the derived credential. With it, ICAM and EMM solutions can be integrated using a common interface, thereby, only requiring one SDK for application derived credential access. One solution is to create on-device middleware or common derived credential app for ICAM and EMM integration with one published SDK, which is also available for app development. See Figure 4. This middleware app stores the credential in software, keychain, or TEE. In this existing approach, each participating ICAM and EMM integrates to the on-device middleware, available for Android and iOS. Another similar solution leverages Windows TPM (instead of a middleware) and Microsoft VSC or Passport* APIs for Windows 10 device apps. The middleware and Windows TPM solution with Microsoft VSC or Passport* have similar benefits. Both approaches allow an enterprise to develop one mobile app no matter the ICAM/EMM environment, as well as, flexibility to change the ICAM vendor or EMM vendor as the mission requires. For Windows 10 devices, this is especially important for those applications built using the Universal WindowsPlatform (UWP) will also be able to run on other Windows 10 devices, PCs, and laptops. These approaches enable one mobility app to be distributed across the enterprise for use, no matter how many different ICAM/EMM combinations are in place. This approach gives mobile applications access to derived credentials using one SDK or from Windows TPM.
8
White Paper
Figure 4. Desirable strategic integration using middleware
Derived credential integration options Derived credential decisions require many considerations before you can determine the best approach to ICAM, EMM, and mobile application requirements. From this, three categories of ICAM-EMM integrations are described: limited baseline, tactical integration, and strategic integration. Solutions for all of these options exist today but with specific integration dependencies. Limited Baseline A derived credential’s “limited baseline” is sufficient for enterprises not using EMMs and with locked-down or hardened devices that only allow access with VPN or secure browser. The limited baseline leverages the ICAM-derived credential solution, which also means using the ICAM-supplied email and browsing apps. Many of these solutions store the credential in the native keychain. Tactical Integration If an EMM is installed, integration to the ICAM solution is required. In the tactical integration case, it is a direct integration with no middleware. Any custom enterprise applications accessing the derived credential require custom development using the specific ICAM/EMM pair SDK— one unique app for each ICAM/EMM pair. If Windows 10 is the target, then Virtual Smart Card or Passport* APIs are used. The tactical integration option is for enterprises that only use one EMM or ICAM in their environment and aren’t concerned about ICAM/EMM pair changes. If the ICAM/EMM environment changes, application costs become in scope. Strategic Integration The strategic approach uses middleware for ICAM/EMM integration, letting organizations support multiple, different EMM environments. This is the most flexible option, enabling custom enterprise app development to one middleware SDK. This works with any ICAM/EMM pair integrated to the middleware, and lets apps use VSC or Passport* APIs for Windows 10.
9
White Paper
Credential management considerations Derived credentials force changes to the credential management paradigm. This addresses difficulties in keeping primary certifications in synchronization with derived credentials. Four areas pertain to this issue: 1. Secure enrollment and transmittal of placing the credential on the mobile device over a secure path. 2. Best effort mobile device management for credential state change. With mobile communications being a best effort over the air (device can be turned off, disconnected from the network, or any reason communications with the device fails), appropriate communications acknowledgment is required for credential state changes—revoke, suspend, and enroll— among all involved devices. 3.One card or credential with credential derivations that support multiple devices (tablet or phone) attached to one person—one primary credential to many derived credentials. 4. Personal status changes of the credentialed party, such as changes to names, clearance level, location, and validated synchronization with the derived credential
Conclusion Choosing the best integration to support your derived credential solution usually requires integration between ICAM and EMM solutions. Additionally, when evaluating your digital ecosystem, a holistic view of mobility, security, identity and access management, credential management, and use cases should be considered. Making derived credential digital strategy decisions without holistic considerations carries the risk of failing to satisfy mission needs, impacting user experience, and increasing the likelihood of data loss. Three integration options were outlined in this whitepaper: baseline, tactical, and strategic. Most enterprises will use the tactical option and migrate to the strategic option as applications are in play or applications used in a hybrid EMM/ICAM environment.
10
White Paper
About the author Ed Wilmes, U.S. public sector lead strategic mobility architect Wilmes has more than 27 years of experience in mobility and communications. His many roles encompass research and development, product development, program management, and solution architecture for defense and commercial industries. Wilmes has master and bachelor degrees in electrical engineering. Wilmes presented published research at IEEE conferences, HPE Discover, Enterprise Connect conferences, and was a panelist speaker at the Smart Card Alliance. He holds a U.S. patent on digital device communications with other patents pending on relative mobile privacy. Wilmes is an Open Group-certified master architect and a member of the Open Group Master Architect Review Board, which certifies architects. In addition, he is a PMI-certified project management professional. He has brought to market products winning Internet Telephony’s Product of the Year award, and developed wireless technology in a startup that was purchased by Deutsche Telecom and renamed T-Mobile. While at DXC Technology, Wilmes has served as worldwide lead mobility architect, worldwide UC&C portfolio strategist, and Americas lead presales solution architect.
11
White Paper
Learn more at www.dxc.technology/ workplace_and_mobility
About DXC DXC Technology (NYSE: DXC) is the world’s leading independent, end-to-end IT services company, helping clients harness the power of innovation to thrive on change. Created by the merger of CSC and the Enterprise Services business of Hewlett Packard Enterprise, DXC Technology serves nearly 6,000 private and public sector clients across 70 countries. The company’s technology independence, global talent and extensive partner network combine to deliver powerful next-generation IT services and solutions. DXC Technology is recognized among the best corporate citizens globally. For more information, visit www.dxc.technology www.dxc.technology
© 2017 DXC Technology Company. All rights reserved.
DXC_4AA5-9196ENW. March 2017
Derived credentials: Choosing the right solution
White Paper
Table of contents
Executive summary
Executive summary
2
Derived credentials and digital IDs
2
Holistic digital approach
2
The challenges
3
Derived credential considerations
3
Strategic approach
6
Derived credential integration options
7
Credential management considerations
7
Conclusion
8
About the author
8
Mobility is rapidly evolving—with each device release, operating system (OS) release, new security issue, Enterprise Mobility Management (EMM) evolution, and productivity solution. Enterprises are embracing mobility and responding to user demands for productive mobile solutions. Users want their device, applications (apps), and network access to just work—without numerous passwords or card readers. Enterprises want secure interactions and centralized control, while maximizing productivity without data loss. Digital IDs or derived credentials help enable these mission and user demands. Derived credentials are driven by the user experience, increased adoption, productivity, and security. With digital ecosystems, you need a holistic view of mobility, security, identity and access management, credential management, and use cases to make decisions for derived credential solutions. This paper discusses considerations that help you choose the right derived credential solution for your enterprise. Derived credentials and digital IDs The National Institutes of Standards and Technology (NIST) defines the derived credential as: “A credential issued based on proof of possession and control of a token associated with a previously issued credential, so as not to duplicate the identity proofing process.” In the federal government, these credentials are derived from a common access card (CAC) or a personal identity verification (PIV) card. They can be used for mobile application authentication, encryption, and signing with a derived credential placed on the mobile device per the federal CAC/PIV model covered by NIST 800-157. Derived credentials are special-case digital IDs generated from a CAC or PIV card. They are created using a credential chain to a certificate authority and placed on a mobile device. A digital ID can be any form of ID or rights-management credential. Examples include a driver’s license or the digital equivalent of any state or local ID. Digital IDs for financial access can be placed on mobile devices, enabling financial transactions similar to Apple Pay or Google Wallet. In addition, digital IDs can be created for insurance cards and entitlement rights or to represent other identifiers. The primary uses for derived credentials include network and computer systems login, digital signatures and encrypted email, secure browsing, application access, enterprise artifacts access, and controlled physical access. Holistic digital approach The motivation for derived credentials include eliminating card readers, increasing user adoption, mobility, mission value, new risk mitigation methods, and reducing costs. Using derived credentials is a user experience and cost-reduction discussion encompassing security requirements and especially preventing data loss. A derived credential on a smartphone combines something you have and something you know in a device you use every day. These motivations let you use derived credentials placed on a mobile device as you would a traditional physical card credential, and it offers new ways to combine technologies not possible before.
2
White Paper
In traditional credential management, once a user is sponsored, enrolled, and adjudicated, a card or token is issued and activated. Then enrollment and issuance processes are complete, giving users access. Placing a derived credential on a mobile device is just the beginning. Depending on the use cases and security requirements, where and how the derived credential is placed on the device impacts the enterprise’s ability to realize full value and satisfy its needs. Without holistic digital considerations, use cases are limited, and data loss is possible, even with a derived credential conforming to NIST Office of Management and Budget level of assurance (LOA) 4 (very high assurance level). The challenges Mobility has unique manifestations based on enterprise and user requirements and experiences. There are three general mobility methods enterprises can employ to govern data access. The first method provides a fully locked-down device to the employee, where an enterprise mobility management (EMM) solution is not necessarily installed. However, security measures, for example, placing a hardened Android image on the device or limiting access to certain locations or access points are in the policy. VPNs are also used in this method, which is the least flexible and requires commonly overlooked support infrastructure and costs. The second method uses a browser-based approach. The commercially available device accesses information via a browser, secure browser, or mobile web application. In this method, no enterprise data is stored on the device. However, user experience is governed by specific network access and bandwidth. To enforce this method, an EMM may be provisioned to prevent data loss. The last method comprises placing an EMM on the commercially available device that gives the enterprise device management, application, and policy enforcement control over the device or more importantly, control over the enterprise data. Figure 1. Derived credential evaluation flow
Derived credential considerations Four aspects must be evaluated, including: • Mission goals, drivers, and use cases • Security protecting mission data • Device policy • Integrations 3
White Paper
Mission Mobility security and derived credentials must be considered along with mission goals, drivers, and use cases because of solution dependencies. Otherwise, erroneous outcomes are probable, such as unintended data loss, not being able to use mobile apps as expected, mobility management issues and failures, and a poor user experience resulting in lower adoption. Security In addition to the derived credentials, you must evaluate data protection, including the level of data-loss risk you can tolerate based on derived credential compromise, device compromise, lost or stolen device, and data loss from user actions (for example, copy-sensitive email or document data) on the device. These answers drive whether an EMM solution is required, if a hardened OS is required, and where the derived credential is stored on the device. Storage location Storage location directly impacts the NIST LOA, which addresses derived credential tampering and other risks. See Table 1. Control over the derived credential storage location is governed by one or more of the following: • Device manufacturer • Operating system • Identity credential access management (ICAM) solution • EMM solution
4
White Paper
Table 1. Derived credential storage options
Device Using results from mission and security analysis, you must choose the method to procuring, deploying, and enabling device connectivity to your enterprise. Policies to consider include: • Bring your own device (BYOD) or organization-provided devices • NIST LOA requirements • Enterprise hardened OS devices • Secure devices • Enterprise-required mobile devices with Windows, iOS, Android, or BlackBerry • Enterprise mobility management integration with laptops, desktops, or workstations These considerations determine which device management is required. Integration Most enterprises use an EMM solution to manage their enterprise-issued mobile devices and BYODs for policy enforcement, enterprise data access, security augmentation, and data loss prevention (DLP).
5
White Paper
EMM systems are used to manage specific enterprise apps, which often require derived credential authentication, encryption, or signing. In this analysis, use cases and security must be kept in the forefront. It’s possible to adopt a derived credential solution that doesn’t prevent data loss or conflict with your EMM solution. For this reason, the ICAM–EMM integration strategy requires evaluation. Consider, for example, if your organization will use the same or different ICAM solution for all sub entities. Also consider if an EMM solution will be used throughout the enterprise, if at all, or will other EMMs be used for the sub entities within the organization. These issues will determine if an ICAM–EMM integration is necessary and specifically how the ICAM–EMM solutions are integrated. Keep in mind these integrations directly impact the mobile app usability, data loss prevention, and user experience. For example, if a mobile application is used across the enterprise with sub entities using different EMMs or different ICAMs, then you must decide which ICAM, EMM, or middleware software development kit (SDK) to use for application-derived credential access. To further understand the potential integration limitations between ICAM and EMM solutions, we need to understand basic EMM function, current ICAM derived credential solutions, and potential mobile application impacts. EMM functionality Most EMMs provide a secure encrypted container on the device as a repository for enterprise apps and customized secure apps for email and browsing; all are used to prevent data loss. The container encapsulates enterprise interests from personal interests on the device. This container requires authentication for access per established enterprise policy. It can authenticate, using the derived credential. In addition to container authentication, enterprise mobile apps may require authentication, signing, and encryption using the derived credential. The EMM enforces enterprise policies and prevents using native OS apps for enterprise email and browsing because there is no enforcement, monitoring, or control over them. Outside the EMM, container enterprise data and applications are inaccessible by native apps. ICAM derived credential solutions Looking at current derived credential ICAM solutions, ICAM vendors develop an encapsulated derived credential application. In addition, the ICAM vendor solution provides secure email and secure browsing mobile apps that work with the ICAMderived credential app. This approach, however, has challenges as the ICAM email and browsing apps may conflict with those provided by the EMM already installed on the device. The ICAM apps may not be subject to enterprise policy enforcement using the EMM. The EMM typically does not have access to the ICAM derived credential app without a tight direct integration using an ICAM provided SDK. It also means that enterprise mobile applications don’t have access to the ICAMderived credential controlled by the vendor derived credential app unless they are developed with the ICAM SDK. For most enterprises, this means a derived credential management system or ICAM solution must integrate with the EMM solution to support usable derived credentials on the device. 6
White Paper
ICAM–EMM integration mobile application considerations Tight, direct integrations are prevalent between ICAM and EMM solutions to resolve joint use of derived credentials. Current approaches are tactical; see Figure 2. With integrations that are custom and specific to each specific ICAM/EMM vendor pair involved, a proprietary SDK is often required for mobile apps. Each line in Figure 2 represents an integration that would potentially use a unique application SDK under the current approach. Using this tactical approach, apps are compiled specific to the customer ICAM/EMM environment pair’s SDK, causing potential for future unforeseen application development costs, application signing challenges, and environment inflexibility.
Figure 2. Undesirable tactical integrations
For a more simplistic approach, app developers want one app to be signed and distributed to the iTunes, Play Store, Windows, or enterprise app store. They want to eliminate the need to recompile an app targeted for a specific OS for each specific ICAM/EMM environment pair using a related SDK. With this ICAM/EMM tactical integration paradigm, if the enterprise has different departments or groups that use different ICAM/EMM environment pairs, then mobile app instantiation is necessary for each ICAM/EMM pair using the pertinent SDK. See Figure 3. This is an undesirable scenario, specifically, because it becomes an enterprise and lifecycle management problem, as well as an application development issue. It’s an enterprise problem because there may be unexpected future events when an ICAM or EMM solution needs to change. It’s a lifecycle management problem for tracking which instantiated app is used by which ICAM/ EMM environment. It’s an application development issue because it requires multiple versions of the same app for each ICAM/EMM pair. Following is an approach to address this challenge.
7
White Paper
Figure 3. One application requires unique changes for each ICAM/EMM pair for the same OS target
Strategic approach If you have multiple sub entities with different EMMs that require the same mobility app, you need a strategic approach to maximize benefits from the derived credential. With it, ICAM and EMM solutions can be integrated using a common interface, thereby, only requiring one SDK for application derived credential access. One solution is to create on-device middleware or common derived credential app for ICAM and EMM integration with one published SDK, which is also available for app development. See Figure 4. This middleware app stores the credential in software, keychain, or TEE. In this existing approach, each participating ICAM and EMM integrates to the on-device middleware, available for Android and iOS. Another similar solution leverages Windows TPM (instead of a middleware) and Microsoft VSC or Passport* APIs for Windows 10 device apps. The middleware and Windows TPM solution with Microsoft VSC or Passport* have similar benefits. Both approaches allow an enterprise to develop one mobile app no matter the ICAM/EMM environment, as well as, flexibility to change the ICAM vendor or EMM vendor as the mission requires. For Windows 10 devices, this is especially important for those applications built using the Universal WindowsPlatform (UWP) will also be able to run on other Windows 10 devices, PCs, and laptops. These approaches enable one mobility app to be distributed across the enterprise for use, no matter how many different ICAM/EMM combinations are in place. This approach gives mobile applications access to derived credentials using one SDK or from Windows TPM.
8
White Paper
Figure 4. Desirable strategic integration using middleware
Derived credential integration options Derived credential decisions require many considerations before you can determine the best approach to ICAM, EMM, and mobile application requirements. From this, three categories of ICAM-EMM integrations are described: limited baseline, tactical integration, and strategic integration. Solutions for all of these options exist today but with specific integration dependencies. Limited Baseline A derived credential’s “limited baseline” is sufficient for enterprises not using EMMs and with locked-down or hardened devices that only allow access with VPN or secure browser. The limited baseline leverages the ICAM-derived credential solution, which also means using the ICAM-supplied email and browsing apps. Many of these solutions store the credential in the native keychain. Tactical Integration If an EMM is installed, integration to the ICAM solution is required. In the tactical integration case, it is a direct integration with no middleware. Any custom enterprise applications accessing the derived credential require custom development using the specific ICAM/EMM pair SDK— one unique app for each ICAM/EMM pair. If Windows 10 is the target, then Virtual Smart Card or Passport* APIs are used. The tactical integration option is for enterprises that only use one EMM or ICAM in their environment and aren’t concerned about ICAM/EMM pair changes. If the ICAM/EMM environment changes, application costs become in scope. Strategic Integration The strategic approach uses middleware for ICAM/EMM integration, letting organizations support multiple, different EMM environments. This is the most flexible option, enabling custom enterprise app development to one middleware SDK. This works with any ICAM/EMM pair integrated to the middleware, and lets apps use VSC or Passport* APIs for Windows 10.
9
White Paper
Credential management considerations Derived credentials force changes to the credential management paradigm. This addresses difficulties in keeping primary certifications in synchronization with derived credentials. Four areas pertain to this issue: 1. Secure enrollment and transmittal of placing the credential on the mobile device over a secure path. 2. Best effort mobile device management for credential state change. With mobile communications being a best effort over the air (device can be turned off, disconnected from the network, or any reason communications with the device fails), appropriate communications acknowledgment is required for credential state changes—revoke, suspend, and enroll— among all involved devices. 3.One card or credential with credential derivations that support multiple devices (tablet or phone) attached to one person—one primary credential to many derived credentials. 4. Personal status changes of the credentialed party, such as changes to names, clearance level, location, and validated synchronization with the derived credential
Conclusion Choosing the best integration to support your derived credential solution usually requires integration between ICAM and EMM solutions. Additionally, when evaluating your digital ecosystem, a holistic view of mobility, security, identity and access management, credential management, and use cases should be considered. Making derived credential digital strategy decisions without holistic considerations carries the risk of failing to satisfy mission needs, impacting user experience, and increasing the likelihood of data loss. Three integration options were outlined in this whitepaper: baseline, tactical, and strategic. Most enterprises will use the tactical option and migrate to the strategic option as applications are in play or applications used in a hybrid EMM/ICAM environment.
10
White Paper
About the author Ed Wilmes, U.S. public sector lead strategic mobility architect Wilmes has more than 27 years of experience in mobility and communications. His many roles encompass research and development, product development, program management, and solution architecture for defense and commercial industries. Wilmes has master and bachelor degrees in electrical engineering. Wilmes presented published research at IEEE conferences, HPE Discover, Enterprise Connect conferences, and was a panelist speaker at the Smart Card Alliance. He holds a U.S. patent on digital device communications with other patents pending on relative mobile privacy. Wilmes is an Open Group-certified master architect and a member of the Open Group Master Architect Review Board, which certifies architects. In addition, he is a PMI-certified project management professional. He has brought to market products winning Internet Telephony’s Product of the Year award, and developed wireless technology in a startup that was purchased by Deutsche Telecom and renamed T-Mobile. While at DXC Technology, Wilmes has served as worldwide lead mobility architect, worldwide UC&C portfolio strategist, and Americas lead presales solution architect.
11
White Paper
Learn more at www.dxc.technology/ workplace_and_mobility
About DXC DXC Technology (NYSE: DXC) is the world’s leading independent, end-to-end IT services company, helping clients harness the power of innovation to thrive on change. Created by the merger of CSC and the Enterprise Services business of Hewlett Packard Enterprise, DXC Technology serves nearly 6,000 private and public sector clients across 70 countries. The company’s technology independence, global talent and extensive partner network combine to deliver powerful next-generation IT services and solutions. DXC Technology is recognized among the best corporate citizens globally. For more information, visit www.dxc.technology www.dxc.technology
© 2017 DXC Technology Company. All rights reserved.
DXC_4AA5-9196ENW. March 2017
