New Identity Powerhouse
Many of you probably noticed the merger of SCM Microsystems and Bluehill ID last week to form Identive Group (http://www.identivegroup.com/). SCM Microsystem's component business with Bluhill's smart card properties will make a very strong combination. While this market has been led by HID, they are potentially very vulnerable to a forward-thinking Identive Group. Identive Group with SCM components, MultiCard, and Hirsch software is a true competitor.
God Bless the people of Haiti!
Join me in donating to the American Red Cross http://www.redcross.org
Physical & Logical Identity Convergence
CONVERGENCE
Convergence of physical and logical security is more than the consolidation of job titles; it is a fundamental improvement in network architecture. Convergence assures trusted enterprise workflow, creating a more secure and efficient infrastructure. Convergence is almost a science; it is not simply interoperability, but is built into the architecture as an identity framework. The clearest example is the United States Federal government’s Personal Identity Verification (PIV) program, an identity framework for all government employees and contractors. Our inspiration is gained from their success and the National Institute of Standards and Technology’s (NIST’s) comprehensive standards architecture. It has been our belief, since 2005, that PIV forms the basis for a fundamental change in academic and enterprise workflow, based on the convergence of identity across the network.
IAM is pleased to present CONVERGENCE, a series of whitepapers focusing on the future of security in academia and industry. Together we hope these papers help consolidate your thinking, and raise awareness of the value of an integrated security framework, a converged security architecture. Like any architecture it begins on paper, we strongly recommend the investment in a “Blueprint” document clearly detailing your goals and objectives. This is a long-term process with long-term objectives, but like any architecture it impacts short-term decisions. Today, a blueprint helps to guide resource planning, disaster recovery, construction standards, and technology investment. Planning will guide the university or enterprise to a more secure, compliant, audit-able, and efficient architecture.
What is identity? At its roots identity is a process of accreditation: are you who you claim to be? Identity is a set of processes and procedures that provide a basis for trust, whether on the physical edge, a door, or on the network. Identity maps to rights and privileges whether it is physical, logical, or federated to external domains. Identity is a singular concept of providing access privileges (physical or logical) to the individual standing in front of his or her supervisor/administrator. But, identity in the university or enterprise environment is hardly singular. How many identities do you have professionally and personally? We use an identity card to pass security in the morning or to receive a 15% discount at the café, but need a separate collection of user names and passwords on the log into the network? Some universities and enterprises use cryptographic tokens to assure trusted authentication, costing a university or enterprise at least $60 per person/per year in TCO (total cost of ownership), but investing in a smartcard is too expensive? Convergence is about architecture, a framework for enhanced security, compliance and audit-ability across all segments of the educational or enterprise environment. Convergence requires an investment in advanced cryptography and small changes to badging and policy. Convergence drives efficiency and a positive return on the investment. Convergence is today’s technology.
Less than a decade ago, IT systems were “stovepipes,” legacy systems developed for a specific purpose that did not interoperate with other systems. Security mirrored that trend, each application having its own security system and policy. More recently we have migrated to single-sign-on (SSO) functionality, whereby we authenticate once to the network and are authorized to multiple applications and services. Many saw SSO as convergence; the convergence of multiple user names and passwords into a single identity, but this is not our definition. SSO was a great step, but now we need to unify security physical and logical. We espouse one unified identity framework with levels of identity assurance associative to the level of security required for specific room access, application authentication, service log-on, or 3rd party authentication. Advances in technology have made the convergence of identity practical, necessary, and essential.
Convergence is necessary to address the following challenges:
• Disparate security management.
Employees manage numerous credentials (identity cards, user ID/passwords or pins) for numerous unique and independent systems. As security concerns have become greater, the required periodic password changes and complexity of password construction have all become more stringent, exacerbating challenges to memorization and management.
• Inconsistent system-security usage, policies and procedures.
Inconsistent identity policies within a domain, or externally in a partner’s domain, create challenges as to the root authority to base trust upon. Moving to a standards based approach to identity will build cross-domain trust and greater efficiency.
• Evolving nature of the Network
System-wide security means so much more in 2009 than a few short years ago. The University or Enterprise network hosts physical security (access control, IP cameras, Alarm Panels), network security, and provides Identity Services to external networks (SAML Assertions). While IT devices are increasing exponentially, the percentage of systems that are nomadic in their mission, wireless or dynamic in their physical location, is also increasing. Together they form a “Perfect Storm;” and, if you were in New England on that fateful day, we all went to work that morning under a brilliant sun and calm breezes.
• Need for greater trust.
Development of trust involves authentication by each of the parties of a transaction to the level of assurance required by the other party in order to proceed. Universities or global enterprises need to agree on technical definitions for levels of trust, and the standards to measure levels of trust (i.e., metrics).
• Interoperability shortfalls.
Interoperability will be achieved by developing a bridging function that enables disparate identity systems and federations of systems to exchange identity information and reuse existing credentials. This bridging function will permit individual organizations to verify identity claims by querying the data-stores held by others.
A converged identity architecture establishes a pro-active (v. reactive) approach to identity and enterprise security. If we have a unified identity framework then we restrict access to those we know, we establish stringent policies and procedures to assure compliance. Today all security applications should run across the Internet Protocol or IP network, and the foundation of that security is a trusted identity framework which can be easily managed and audited.
We often speak of security as a Board level concern, or a Trustee level concern. Having weak access control policies (ex: bar-code based ID Cards) while investing in enhanced Intrusion Prevention on the network is nonsensical; yet we see it all the time. Building dormitories with magnetic stripe technology in 2009 ignores the reality of the useful life of this technology and others. Placing IP based surveillance cameras in public spaces but not addressing network concerns, storage policies, and video management is equally troubling. Decision makers must realize the value of a comprehensive security plan and execute upon it. We would never build a building without a plan, how are we going to manage security across the university or enterprise environment without one?
Inevitably we hear about divisional directors and their domains, and we too often see politics come before practice. Security is not a secondary decision or a patch job, it is a primary business driver. Proper security and architecture drive improved business function and efficiency.
A Practical Medium
Convergence is in the cards, literally! Convergence is enabled based on new smartcard technology and its related standards, which utilize embedded processors on the smartcard. Clearly, an identity card is not new; this is not your father’s card. Today’s smartcards are capable of carrying multiple identities, signing credentials and biometric data; and can process challenges directly on the card. It is the advancements made in smartcard technology and international standards that allow us to practice convergence.
Smartcards first emerged about a decade ago, vendors began to present smartcards or memory based cards, capable of passing an encrypted identity to another application (ex: a door reader or a copy machine). These memory cards were application siloed and enabled the simple allocation of memory space; one of the more popular applications being a purse for micro-payments. These memory-based smartcards were themselves a siloed approach to security. These first generation smartcards were a generational shift from magnetic stripe and later proximity cards. The next generation of processor based smartcards: Multos or Java Cards allow the card to be identity centric and not segmented by application. Newer smartcards can have a challenge processed directly on the processor of the card, digital keys can be securely seeded with the card, biometrics can securely stored on the card; all allowing for multiple levels of identity authentication. International Standards allow for applications to uniformly use smartcards to authenticate users across physical and logical security domains.
One of the earliest and most influential uses of newer smartcards is the United States Department of Defense (DOD) Common Access Card (CAC), which was designed to be the standard DOD identity card and the primary card to enable both physical access to buildings and logical access to the DOD network. Since October 2000, the DOD has issued over 12 million CAC cards and implemented a worldwide application architecture. Today, support for the CAC card can be found on Windows, Apple, and Linux operating systems, and with portable mobile devices (such as the Blackberry smart phone).
The Federal Government's move to smart cards accelerated with the issuance of Homeland Security Presidential Directive 12 (HSPD-12) on August 27, 2004. HSPD-12 mandates the need “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy by establishing a mandatory, Government-wide standard for secure and reliable forms of identification.” HSPD-12 specifically calls for the use of a common identification credential for “gaining physical access to federally controlled facilities and logical access to federally controlled information systems.” As a result of this directive, the National Institute of Standards and Technology (NIST) published FIPS 201. FIPS 201 defines the identity vetting, enrollment, and issuance requirements for a common identity credential and the technical specifications for a government employee and contractor ID card: the PIV card.
A growing number of approved vendors of logical and physical access systems and applications have developed products built on FIPS 201 and industry standards for smart cards. FIPS 201 has attracted international attention and is under consideration for government, public safety, and critical infrastructure personnel in other countries. Within the next five years, 12 million PIV cards will be used in the Federal Government alone, driving a significant expansion of FIPS 201 infrastructure and applications. And, FIPS 201 is the framework for most State’s first responder cards or FRAC (First Responder Access Cards).
Using processor based smart cards enables the issuer to assert that the receiving party can place a high degree of trust in the information on the card. This information can include personal information (for example, a biometric or signed digital photo) or privileges (such as digital certificates that allow computer logon). In any secure identity credentialing system, the issuance process is as important as the credential’s security. The issuance process needs to bind the person to a level of accreditation, are they who they claim to be? And, after the credential is issued, the credential life cycle management process needs to incorporate authentication, revocation, and reissuance processes. One can only trust a credential if they believe that the issuance and life cycle management processes are secure.
Our CONVERGED whitepaper series will look more closely at the technology and standards of smartcards: It’s in the Cards. This will be the second installment of the Series.
The Importance of PKI
Public Key Infrastructure (PKI) technology is a fundamental component of the converged identity framework. Public key cryptography provides the trusted framework for absolute assurance of identification, integrity, authenticity, confidentiality, and non-repudiation within services. The public key component provides electronic credentials that are unique, un-forgeable, and trusted for use in network transactions, and supports strong authentication for a broad range of human and non-person entities (devices) requesting access to networks, information and resources. A PKI credential carried on a smartcard provides a card which can be challenged at the physical perimeter. Now, you are more than just the card, you are also something the cardholder knows. This is the principal behind cryptographic tokens, but in a common and easily used form factor, a smartcard. The PKI-based authentication provides the ability to log on to network or Web-based service, thus eliminating the inherent vulnerabilities of user ID/password or pin. In fact, the DOD has reduced unauthorized log-on attempts by 46 percent because of the requirement for all DOD personnel log on to unclassified networks using a smartcard with their associative PKI certificate.
A PKI framework provides a secure infrastructure and common standards for identity proofing, credential issuance and revocation management. It is the framework and services that provide for generation, production, distribution, control, accounting and destruction of identity. A PKI framework is based on the issuance of a unique private key which securely resides on the smartcard; in fact, the private key is non-exportable from the card. The private key is cryptographically associated with a unique public key, which by its very name is public. Therefore, the cardholder can “publish” their public key to be used to challenge the unique private key. It is this challenge and response that makes PKI so unique. Further, we only allow the private key to be accessed based on a second challenge, this could be as simple as a pin or more complex as in a biometric (fingerprint) also stored on the card. In the later example, the cardholder would place their card in a biometric reader, the cardholder would swipe their fingerprint, the card would verify the fingerprint, and the private key would be unlocked. The processing all happens in milliseconds even though our human reaction may be in seconds.
The PKI framework provides a foundation for converged security services to include access control, network authentication, WAN authentication, wireless authentication and access to web services (internally or externally). PKI also supports digital signatures, data integrity, non-repudiation, and confidentiality when associated with encryption. PKI can be used to facilitate broader usage for network logon, e-mail signing, and certificate-based authentication for Web servers. PKI offers a centralized management framework to authorize a new credential or revoke an existing key. Imagine if your academic institution or enterprise can manage all security through one management function, the trust of a single key.
Note: Authentication keys should only be used for authentication, authorizing the cardholder to a building, room, network, or web service. Digital signing and/or encryption should be performed by additional keys created for those purposes, each of which can be stored on the same smartcard.
The Service Oriented Architecture
Universities and enterprises all seek interoperability of their legacy systems, mainframe, ERP, and CRM systems with newer technologies running on web-facing application servers. These web services are a gateway to enabling reuse of critical “back-end” technologies. The Service Oriented Architecture (“SOA”) is a distributed computing framework for these web services deployments. SOA uses standardized middleware components to enable information to flow as needed, and delivers application agility. The goal of SOA is to minimize reworking of existing legacy applications, extend their useful lives, and expand their potential for reuse across a university or enterprise.
As universities and industry empower their SOA deployments, messages will be exchanged between web services internally and externally. Trust is established based on a message level security standard: WS-Security. Under the WS-Security standard the requesting web service signs an assertion of trust to the receiving service. This assertion is called a SAML assertion, which stands for Security Assertion Mark-up Language. Without getting into a more complex technology discussion, the assertion carries authentication properties. In essence the assertion is signed by the identity service, in this case the requesting service, or is signed by the user. Were a service to use basic usernames and passwords, we have done little to solve our identity silos and little to enhance security. But, a converged model, whereby a private key can be challenged by a relying party and used to sign the assertion, forms a secure and trusted identity framework. As important, a unified identity system that issues or revokes a credential when someone joins or leaves an institution enhances the trust, compliance and audit-ability of the SOA.
Our CONVERGED whitepaper series will look more closely at identity on the SOA in: Enterprise SOA Trust. This will be the third installment of the Series.
Conclusion
An identity framework must be consistent with the long-term vision, which can support all entities from users to devices to systems, both physical and logical. The identity capability must be flexible, agile, dynamic, audit-able and scalable to account for and respond to the numerous changes in most organizations and mission operations. The need for higher levels of confidence in claimed identities and the safeguarding of data associated with identities of people, systems, processes and organizations underline the demand for continued identity evolution. University IT or Enterprise staffs must manage local entities (e.g., departments, sponsors of devices and owners of applications); they will have to be registered, issued credentials, and systems configured to use the identity framework. This requires coordinated efforts, standards-based implementations, synchronized execution and a secure IT infrastructure to support the common security architecture.
A successful identity framework will also be required to support a wide variety of privacy and security levels, ranging from low-security password-based single-factor authentication to high-end attribute-based systems employing state of the art privacy-enhancing techniques. Technical aspects of this problem can be addressed conceptually by designing an appropriate identity framework. The identity framework should:
• Associate people and devices with an identity (PKI, biometric, other). This identity will be used to access facilities and networks;
• Use shared standards, protocols and infrastructure to support both logical and physical access to resources; and
• Federate credentials between trusted domains based on common standards and root trust.
Convergence of physical and logical security is more than the consolidation of job titles; it is a fundamental improvement in network architecture. Convergence assures trusted enterprise workflow, creating a more secure and efficient infrastructure. Convergence is almost a science; it is not simply interoperability, but is built into the architecture as an identity framework. The clearest example is the United States Federal government’s Personal Identity Verification (PIV) program, an identity framework for all government employees and contractors. Our inspiration is gained from their success and the National Institute of Standards and Technology’s (NIST’s) comprehensive standards architecture. It has been our belief, since 2005, that PIV forms the basis for a fundamental change in academic and enterprise workflow, based on the convergence of identity across the network.
IAM is pleased to present CONVERGENCE, a series of whitepapers focusing on the future of security in academia and industry. Together we hope these papers help consolidate your thinking, and raise awareness of the value of an integrated security framework, a converged security architecture. Like any architecture it begins on paper, we strongly recommend the investment in a “Blueprint” document clearly detailing your goals and objectives. This is a long-term process with long-term objectives, but like any architecture it impacts short-term decisions. Today, a blueprint helps to guide resource planning, disaster recovery, construction standards, and technology investment. Planning will guide the university or enterprise to a more secure, compliant, audit-able, and efficient architecture.
What is identity? At its roots identity is a process of accreditation: are you who you claim to be? Identity is a set of processes and procedures that provide a basis for trust, whether on the physical edge, a door, or on the network. Identity maps to rights and privileges whether it is physical, logical, or federated to external domains. Identity is a singular concept of providing access privileges (physical or logical) to the individual standing in front of his or her supervisor/administrator. But, identity in the university or enterprise environment is hardly singular. How many identities do you have professionally and personally? We use an identity card to pass security in the morning or to receive a 15% discount at the café, but need a separate collection of user names and passwords on the log into the network? Some universities and enterprises use cryptographic tokens to assure trusted authentication, costing a university or enterprise at least $60 per person/per year in TCO (total cost of ownership), but investing in a smartcard is too expensive? Convergence is about architecture, a framework for enhanced security, compliance and audit-ability across all segments of the educational or enterprise environment. Convergence requires an investment in advanced cryptography and small changes to badging and policy. Convergence drives efficiency and a positive return on the investment. Convergence is today’s technology.
Less than a decade ago, IT systems were “stovepipes,” legacy systems developed for a specific purpose that did not interoperate with other systems. Security mirrored that trend, each application having its own security system and policy. More recently we have migrated to single-sign-on (SSO) functionality, whereby we authenticate once to the network and are authorized to multiple applications and services. Many saw SSO as convergence; the convergence of multiple user names and passwords into a single identity, but this is not our definition. SSO was a great step, but now we need to unify security physical and logical. We espouse one unified identity framework with levels of identity assurance associative to the level of security required for specific room access, application authentication, service log-on, or 3rd party authentication. Advances in technology have made the convergence of identity practical, necessary, and essential.
Convergence is necessary to address the following challenges:
• Disparate security management.
Employees manage numerous credentials (identity cards, user ID/passwords or pins) for numerous unique and independent systems. As security concerns have become greater, the required periodic password changes and complexity of password construction have all become more stringent, exacerbating challenges to memorization and management.
• Inconsistent system-security usage, policies and procedures.
Inconsistent identity policies within a domain, or externally in a partner’s domain, create challenges as to the root authority to base trust upon. Moving to a standards based approach to identity will build cross-domain trust and greater efficiency.
• Evolving nature of the Network
System-wide security means so much more in 2009 than a few short years ago. The University or Enterprise network hosts physical security (access control, IP cameras, Alarm Panels), network security, and provides Identity Services to external networks (SAML Assertions). While IT devices are increasing exponentially, the percentage of systems that are nomadic in their mission, wireless or dynamic in their physical location, is also increasing. Together they form a “Perfect Storm;” and, if you were in New England on that fateful day, we all went to work that morning under a brilliant sun and calm breezes.
• Need for greater trust.
Development of trust involves authentication by each of the parties of a transaction to the level of assurance required by the other party in order to proceed. Universities or global enterprises need to agree on technical definitions for levels of trust, and the standards to measure levels of trust (i.e., metrics).
• Interoperability shortfalls.
Interoperability will be achieved by developing a bridging function that enables disparate identity systems and federations of systems to exchange identity information and reuse existing credentials. This bridging function will permit individual organizations to verify identity claims by querying the data-stores held by others.
A converged identity architecture establishes a pro-active (v. reactive) approach to identity and enterprise security. If we have a unified identity framework then we restrict access to those we know, we establish stringent policies and procedures to assure compliance. Today all security applications should run across the Internet Protocol or IP network, and the foundation of that security is a trusted identity framework which can be easily managed and audited.
We often speak of security as a Board level concern, or a Trustee level concern. Having weak access control policies (ex: bar-code based ID Cards) while investing in enhanced Intrusion Prevention on the network is nonsensical; yet we see it all the time. Building dormitories with magnetic stripe technology in 2009 ignores the reality of the useful life of this technology and others. Placing IP based surveillance cameras in public spaces but not addressing network concerns, storage policies, and video management is equally troubling. Decision makers must realize the value of a comprehensive security plan and execute upon it. We would never build a building without a plan, how are we going to manage security across the university or enterprise environment without one?
Inevitably we hear about divisional directors and their domains, and we too often see politics come before practice. Security is not a secondary decision or a patch job, it is a primary business driver. Proper security and architecture drive improved business function and efficiency.
A Practical Medium
Convergence is in the cards, literally! Convergence is enabled based on new smartcard technology and its related standards, which utilize embedded processors on the smartcard. Clearly, an identity card is not new; this is not your father’s card. Today’s smartcards are capable of carrying multiple identities, signing credentials and biometric data; and can process challenges directly on the card. It is the advancements made in smartcard technology and international standards that allow us to practice convergence.
Smartcards first emerged about a decade ago, vendors began to present smartcards or memory based cards, capable of passing an encrypted identity to another application (ex: a door reader or a copy machine). These memory cards were application siloed and enabled the simple allocation of memory space; one of the more popular applications being a purse for micro-payments. These memory-based smartcards were themselves a siloed approach to security. These first generation smartcards were a generational shift from magnetic stripe and later proximity cards. The next generation of processor based smartcards: Multos or Java Cards allow the card to be identity centric and not segmented by application. Newer smartcards can have a challenge processed directly on the processor of the card, digital keys can be securely seeded with the card, biometrics can securely stored on the card; all allowing for multiple levels of identity authentication. International Standards allow for applications to uniformly use smartcards to authenticate users across physical and logical security domains.
One of the earliest and most influential uses of newer smartcards is the United States Department of Defense (DOD) Common Access Card (CAC), which was designed to be the standard DOD identity card and the primary card to enable both physical access to buildings and logical access to the DOD network. Since October 2000, the DOD has issued over 12 million CAC cards and implemented a worldwide application architecture. Today, support for the CAC card can be found on Windows, Apple, and Linux operating systems, and with portable mobile devices (such as the Blackberry smart phone).
The Federal Government's move to smart cards accelerated with the issuance of Homeland Security Presidential Directive 12 (HSPD-12) on August 27, 2004. HSPD-12 mandates the need “to enhance security, increase Government efficiency, reduce identity fraud, and protect personal privacy by establishing a mandatory, Government-wide standard for secure and reliable forms of identification.” HSPD-12 specifically calls for the use of a common identification credential for “gaining physical access to federally controlled facilities and logical access to federally controlled information systems.” As a result of this directive, the National Institute of Standards and Technology (NIST) published FIPS 201. FIPS 201 defines the identity vetting, enrollment, and issuance requirements for a common identity credential and the technical specifications for a government employee and contractor ID card: the PIV card.
A growing number of approved vendors of logical and physical access systems and applications have developed products built on FIPS 201 and industry standards for smart cards. FIPS 201 has attracted international attention and is under consideration for government, public safety, and critical infrastructure personnel in other countries. Within the next five years, 12 million PIV cards will be used in the Federal Government alone, driving a significant expansion of FIPS 201 infrastructure and applications. And, FIPS 201 is the framework for most State’s first responder cards or FRAC (First Responder Access Cards).
Using processor based smart cards enables the issuer to assert that the receiving party can place a high degree of trust in the information on the card. This information can include personal information (for example, a biometric or signed digital photo) or privileges (such as digital certificates that allow computer logon). In any secure identity credentialing system, the issuance process is as important as the credential’s security. The issuance process needs to bind the person to a level of accreditation, are they who they claim to be? And, after the credential is issued, the credential life cycle management process needs to incorporate authentication, revocation, and reissuance processes. One can only trust a credential if they believe that the issuance and life cycle management processes are secure.
Our CONVERGED whitepaper series will look more closely at the technology and standards of smartcards: It’s in the Cards. This will be the second installment of the Series.
The Importance of PKI
Public Key Infrastructure (PKI) technology is a fundamental component of the converged identity framework. Public key cryptography provides the trusted framework for absolute assurance of identification, integrity, authenticity, confidentiality, and non-repudiation within services. The public key component provides electronic credentials that are unique, un-forgeable, and trusted for use in network transactions, and supports strong authentication for a broad range of human and non-person entities (devices) requesting access to networks, information and resources. A PKI credential carried on a smartcard provides a card which can be challenged at the physical perimeter. Now, you are more than just the card, you are also something the cardholder knows. This is the principal behind cryptographic tokens, but in a common and easily used form factor, a smartcard. The PKI-based authentication provides the ability to log on to network or Web-based service, thus eliminating the inherent vulnerabilities of user ID/password or pin. In fact, the DOD has reduced unauthorized log-on attempts by 46 percent because of the requirement for all DOD personnel log on to unclassified networks using a smartcard with their associative PKI certificate.
A PKI framework provides a secure infrastructure and common standards for identity proofing, credential issuance and revocation management. It is the framework and services that provide for generation, production, distribution, control, accounting and destruction of identity. A PKI framework is based on the issuance of a unique private key which securely resides on the smartcard; in fact, the private key is non-exportable from the card. The private key is cryptographically associated with a unique public key, which by its very name is public. Therefore, the cardholder can “publish” their public key to be used to challenge the unique private key. It is this challenge and response that makes PKI so unique. Further, we only allow the private key to be accessed based on a second challenge, this could be as simple as a pin or more complex as in a biometric (fingerprint) also stored on the card. In the later example, the cardholder would place their card in a biometric reader, the cardholder would swipe their fingerprint, the card would verify the fingerprint, and the private key would be unlocked. The processing all happens in milliseconds even though our human reaction may be in seconds.
The PKI framework provides a foundation for converged security services to include access control, network authentication, WAN authentication, wireless authentication and access to web services (internally or externally). PKI also supports digital signatures, data integrity, non-repudiation, and confidentiality when associated with encryption. PKI can be used to facilitate broader usage for network logon, e-mail signing, and certificate-based authentication for Web servers. PKI offers a centralized management framework to authorize a new credential or revoke an existing key. Imagine if your academic institution or enterprise can manage all security through one management function, the trust of a single key.
Note: Authentication keys should only be used for authentication, authorizing the cardholder to a building, room, network, or web service. Digital signing and/or encryption should be performed by additional keys created for those purposes, each of which can be stored on the same smartcard.
The Service Oriented Architecture
Universities and enterprises all seek interoperability of their legacy systems, mainframe, ERP, and CRM systems with newer technologies running on web-facing application servers. These web services are a gateway to enabling reuse of critical “back-end” technologies. The Service Oriented Architecture (“SOA”) is a distributed computing framework for these web services deployments. SOA uses standardized middleware components to enable information to flow as needed, and delivers application agility. The goal of SOA is to minimize reworking of existing legacy applications, extend their useful lives, and expand their potential for reuse across a university or enterprise.
As universities and industry empower their SOA deployments, messages will be exchanged between web services internally and externally. Trust is established based on a message level security standard: WS-Security. Under the WS-Security standard the requesting web service signs an assertion of trust to the receiving service. This assertion is called a SAML assertion, which stands for Security Assertion Mark-up Language. Without getting into a more complex technology discussion, the assertion carries authentication properties. In essence the assertion is signed by the identity service, in this case the requesting service, or is signed by the user. Were a service to use basic usernames and passwords, we have done little to solve our identity silos and little to enhance security. But, a converged model, whereby a private key can be challenged by a relying party and used to sign the assertion, forms a secure and trusted identity framework. As important, a unified identity system that issues or revokes a credential when someone joins or leaves an institution enhances the trust, compliance and audit-ability of the SOA.
Our CONVERGED whitepaper series will look more closely at identity on the SOA in: Enterprise SOA Trust. This will be the third installment of the Series.
Conclusion
An identity framework must be consistent with the long-term vision, which can support all entities from users to devices to systems, both physical and logical. The identity capability must be flexible, agile, dynamic, audit-able and scalable to account for and respond to the numerous changes in most organizations and mission operations. The need for higher levels of confidence in claimed identities and the safeguarding of data associated with identities of people, systems, processes and organizations underline the demand for continued identity evolution. University IT or Enterprise staffs must manage local entities (e.g., departments, sponsors of devices and owners of applications); they will have to be registered, issued credentials, and systems configured to use the identity framework. This requires coordinated efforts, standards-based implementations, synchronized execution and a secure IT infrastructure to support the common security architecture.
A successful identity framework will also be required to support a wide variety of privacy and security levels, ranging from low-security password-based single-factor authentication to high-end attribute-based systems employing state of the art privacy-enhancing techniques. Technical aspects of this problem can be addressed conceptually by designing an appropriate identity framework. The identity framework should:
• Associate people and devices with an identity (PKI, biometric, other). This identity will be used to access facilities and networks;
• Use shared standards, protocols and infrastructure to support both logical and physical access to resources; and
• Federate credentials between trusted domains based on common standards and root trust.
SOA Security and Message Validation
Today's IT environment is driven by the need to connect disparate systems into a flexible, unified, efficiently-performing whole. The connected systems may span continents, enterprise and organizational trust domains, and legal jurisdictions. In order to connect, enterprises are turning to Service-Oriented Architecture (SOA) implemented with SOAP-based Web Services and SAML-based federated identity management. This white paper highlights some of the inherent security features and demands of these new technologies and how the Trust Authority System from IAM Technology helps enterprises achieve real-time identity and data validation in a service-oriented environment with a dynamic membership and regulatory compliance requirements.
SOA, Web Services, and Security
Over the past decade, enterprises have realized that in order to be competitive (or in the case of governments, be effective) they need to be able to easily and effectively share services both within their constituent organizations and with other enterprises. The modern approach for doing so is Service-Oriented Architecture (SOA) and most implementations of service oriented architecture used SOAP-based Web Services.
Security, of course, remains paramount and in the case of Web Services, there is a suite of Web Services Security specifications of which the SOAP Message Security specification defines how to use message-level cryptography such as XML Signature and XML Encryption for SOAP messages.
Another security aspect of SOA is authentication – both for signature validation and authorization. In particular, because SOA is geared to sharing services across organizations, a flexible and robust authentication meta-layer is needed and that is why the SAML (Security Assertion Markup Language) specification has been developed.
SAML enables an assertion about an entity's authentication and/or its attributes to be shared among different organizations no matter what authentication mechanisms or identity management infrastructure they use. SAML's inherent support for federated identity has made it the core technology behind industry federated identity initiatives such as the Liberty Alliance Project and Shibboleth. There is also a Web Services Security specification, the SAML Token Profile, defining how to use SAML-based tokens within SOAP messages. And like the SOAP Message Security specification, the SAML core specification also defines how to use XML Signature and XML Encryption to protect messages.
XML Signature and XML Encryption are particularly valuable for securing SOAP and SAML messages because they enable parts of the message to be signed and/or encrypted in accordance with the specific security needs of that part, the signer, and the target audience. For example, if part of a SOAP message is intended to be modified by intermediaries between the sender and the recipient, that part must be left unsigned or else the signature of the originator would become invalid. Similarly, if parts of a SAML message need to be left in the clear or need to be encrypted for different parties, that can be elegantly done with XML Encryption. The SOAP Message Security specification defines how to include and process XML Signature and XML Encryption objects within SOAP messages. Similarly, the SAML specification does the same for SAML assertions. Finally, both the SAML and SOAP Message Security specifications support signed timestamps to help ensure the freshness of the message.
Multi-Party Processing
In a service-oriented environment, the execution of a service may result in a number of SOAP messages being exchanged among a number of different entities. It is important to note that SOAP is designed for more complicated transactions than simple request/response. The design of SOAP enables the same SOAP message to be received, modified, and forwarded to a different party than from the one it was received. In SOAP terminology, intermediaries perform different roles with respect to the same SOAP message. Some intermediaries may add information; some may delete information; and some may only read existing information all in the due process of fulfilling a service.
The SOAP Message Security specification describes how one or more signatures can be applied and validated to ensure the full security of the SOAP message as it travels from the initiator, through the intermediaries, and the ultimate relying party. Figure 1 illustrates a SOAP message as it is transformed from point to point. In the figure, the originator creates a SOAP message and applies a signature (SigORIG) that signs Parts 1 and 2. An intermediary captures the message appends a new part (Part 3), adding its own signature (SigIM) to cover parts 2 and 3 (by counter-signing Part 2, it may be indicating that it has reviewed and approved it). The message then goes to the relying party who verifies both signatures.
Besides signing parts of a SOAP message dealing with the execution of the service, the SOAP Message Security specification also defines the signing of security tokens and references to security tokens within SOAP messages. With regard to the latter, the SOAP Message Security specification defines a special transform that allows an XML Signature to point to a security token reference but actually sign the referenced object, not the reference. Hence, service-oriented environments have the flexibility of signing the security token reference itself, the object pointed to by the security token reference, or doing both.
Compliance
Both SOAP and SAML have features supporting compliance to rules regarding processing and policies. An (optional) feature of SOAP Message Security of particular value to service-oriented environments where compliance is a priority is the ability of a requester to require that a responder provide evidence in the response that the responder validated the signature in the request. This is so that the requestor can be confident that the response is based on unaltered information sent by the requestor. The feature, called SignatureConfirmation, does not disallow intermediaries from modifying non-protected parts of the SOAP message as long as those intermediaries do not maliciously or accidentally modify parts of the SOAP message signed by the requestor.
In SAML, XML Signatures are used to authenticate and protect the integrity of both requests (e.g. a request for an authentication assertion) and responses (an authentication assertion). The SAML specification states that if a SAML assertion contains an XML Signature, then the relying party must not trust the SAML assertion unless the XML Signature is valid. If the signature is valid, the relying party may then assess “the identity and appropriateness of the issuer and may continue to process the assertion in accordance with this specification and as it deems appropriate”.
SAML also uses signatures for signing the Consent attribute. The Consent attribute indicates whether or not the consent of the principal (the one whom the assertion is about) was obtained or not by the issuer of the message (either a request or response) and under what conditions. As examples of consent, consider a service that would like to obtain an assertion from an identity provider about an attribute of a user. The service may need, due to internal privacy policies or government regulations, to obtain the consent of the user before querying certain information about that user. As well, the user's identity provider may need to obtain the consent of the user before providing that information.
Need for Message-Level Security
Other message-level security formats such as PKCS#7 which are not XML-aware do not inherently have the capability of selectively signing and encrypting message parts for different audiences. PKCS#7 does, however, at least provide unbroken message-level security between the originator and the relying party. In contrast to the message-level security provided by XML Signature, XML Encryption, and PKCS#7, is TLS which operates at the transport layer. For direct server to server communication that does not require application-aware, process-aware, policy-aware, auditable, provable security, TLS is sufficient. In the world of SOA, however, one needs end-to-end security that can be tailored to the specific, dynamic needs of enterprises and their applications; and that is historically auditable in order to prove compliance with the internal and external regulations. That kind of higher-level security requires message-level security.
Need for Speed
In a service-oriented environment, message-level security requires access to the public key material of the constituent organizations. This means that there must be a secure, up-to-date repository of the public keys and a highly efficient means of accessing the public keys in that repository. However the nature of service-oriented environments is that they are distributed (often over a wide geographic area), may contain mobile clients, and yet, because the services are intended to enable machine-to-machine communication, high performance is a necessity. And that means that message-level security too must be of the highest performance or else it will be a bottleneck to the system's primary functionality.
The IAM Trust Authority System
The Trust Authority System from IAM Technology is a hardware appliance that incorporates breakthroughs in cryptographic research made at Brown University for the United States Department of Defense. Specifically, the Trust Authority System enables fast and easy distribution of validated public keys in distributed, federated environments such as those built on SOA using SAML and SOAP-based Web Services. It does so by allowing relying parties to efficiently interact with validation responders. A validation responder is an authenticated dictionary widely distributed throughout Layer 7, and among partner organizations. Validation responders reply to queries about the validity of a public key in real time (tested to 54 micro-seconds) locally. An answer from a validation responder can be trusted as if it came from a source. Validation responders can even issue trust in untrusted environments.
These features distinguish the IAM Trust Authority architecture:
• Trust domains can easily update their public key material through XKMS (XML Key Management Specification) messages to the IAM Trust Authority;
• The IAM Trust Authority can efficiently and securely push updates to validation responders throughout a service-oriented environment; and
• The validation responders can provide near-instantaneous, verifiable responses to public key requests from applications.
Dynamic Membership
In a dynamic, federated environment, new members enter and existing members may leave. As members come and go, so must the status of their public keys within the environment.
The X10 Trust Authority architecture makes management of a dynamic membership easy through its straightforward XKMS interface for registering, reissuing, and revoking the public keys securely stored within the X10 Trust Authority. What is unique about the Trust Authority is how it then updates the information base of the validation responders. Through the STMS update mechanism, the IAM Trust Authority can update multiple validation responders using very little bandwidth and requiring minimal processing power internally and within the validation responders. This makes it possible for the organizations within a service-oriented environment to be assured that the relying parties in that environment have the best possible access to up-to-date trust information.
Historically Provable Validation of the Public Key
Compliance requires evidence. In the area of signature validation, one needs evidence that the public key used to validate signature was valid at the time that the validation occurred. As mentioned in the previous section, participating organizations within the service-oriented environment join, leave, or simply update their keys. Yet how can one know whether a particular public key was valid at the time signature was verified?
To do this, the IAM Trust Authority incorporates each update into the existing authentication dictionary in accordance with IAM’s Persistent Authenticated Dictionary (PAD) technology. With PAD, each update to the authenticated dictionary results in an adjunct to the data structure along with a corresponding Basis. To accommodate the time dimension of PAD, the STMS queries for historic validation include an additional parameter for the time instant of interest and the returned answer proofs are similarly cryptographically dependent on the time instants of the corresponding updates to the status of the public key. Consequently, the validation status of a public key can be proved for any time instant and, as such, that proof can be used as evidence for compliance with respect to signature processing and therefore also with respect to identity-related assertions and Web Services transactions.
Real-time Public Key Validation
As mentioned earlier, dynamic, federated, service-oriented environments cannot be bottlenecked by security. Indeed, many of them are incorporating in-line hardware appliances to realize wire-speed processing of secured SOAP and SAML messages.
Whether signature validation is done in hardware or software, doing it efficiently requires real-time responses to public key validation queries. The IAM Trust Authority architecture makes that possible. The high efficiency of an IAM Trust Authority-based deployment is possible because the placing of the validation responders can be optimized for the particular resident infrastructure as the validation responders need not be secured. This is possible thanks to the use of a unique data structure (called a skip list) that enables efficient updating of distributed validation responders and a corresponding cryptographic mechanism that provides trusted proofs to relying parties about the answers received from a validation responder. With the IAM Trust Authority Architecture, system components within a service-oriented environment can now have up-to-date validation status for public keys, and access to those keys, in real time.
Conclusion
Collaboration among enterprises, or within the constituent organizations of a single large enterprise, is being realized today through service-oriented architecture – much of which is being implemented with SOAP-based Web Services to enable advanced communication among devices and with SAML to ensure that participants in the transaction are identified, authenticated, and authorized.
SOAP and SAML, and their respective security specifications, contain many features that are invaluable to implementing multi-party business processes and ensuring that those processes are conducted in compliance with security policies, privacy policies, internal policies, and government policies. These features are designed to be best secured with message-level security; however, message-level security in a service-oriented environment requires real-time public key validation. Now, with the IAM Trust Authority, real-time public key validation is a reality thanks to its implementation of IAM’s advanced cryptographic research. Furthermore, the revolutionary technology behind the IAM Trust Authority architecture supports dynamic membership among the participating enterprises and provides cryptographically provable evidence about the validity or not of a specific public key for future compliance audits.
SOA, Web Services, and Security
Over the past decade, enterprises have realized that in order to be competitive (or in the case of governments, be effective) they need to be able to easily and effectively share services both within their constituent organizations and with other enterprises. The modern approach for doing so is Service-Oriented Architecture (SOA) and most implementations of service oriented architecture used SOAP-based Web Services.
Security, of course, remains paramount and in the case of Web Services, there is a suite of Web Services Security specifications of which the SOAP Message Security specification defines how to use message-level cryptography such as XML Signature and XML Encryption for SOAP messages.
Another security aspect of SOA is authentication – both for signature validation and authorization. In particular, because SOA is geared to sharing services across organizations, a flexible and robust authentication meta-layer is needed and that is why the SAML (Security Assertion Markup Language) specification has been developed.
SAML enables an assertion about an entity's authentication and/or its attributes to be shared among different organizations no matter what authentication mechanisms or identity management infrastructure they use. SAML's inherent support for federated identity has made it the core technology behind industry federated identity initiatives such as the Liberty Alliance Project and Shibboleth. There is also a Web Services Security specification, the SAML Token Profile, defining how to use SAML-based tokens within SOAP messages. And like the SOAP Message Security specification, the SAML core specification also defines how to use XML Signature and XML Encryption to protect messages.
XML Signature and XML Encryption are particularly valuable for securing SOAP and SAML messages because they enable parts of the message to be signed and/or encrypted in accordance with the specific security needs of that part, the signer, and the target audience. For example, if part of a SOAP message is intended to be modified by intermediaries between the sender and the recipient, that part must be left unsigned or else the signature of the originator would become invalid. Similarly, if parts of a SAML message need to be left in the clear or need to be encrypted for different parties, that can be elegantly done with XML Encryption. The SOAP Message Security specification defines how to include and process XML Signature and XML Encryption objects within SOAP messages. Similarly, the SAML specification does the same for SAML assertions. Finally, both the SAML and SOAP Message Security specifications support signed timestamps to help ensure the freshness of the message.
Multi-Party Processing
In a service-oriented environment, the execution of a service may result in a number of SOAP messages being exchanged among a number of different entities. It is important to note that SOAP is designed for more complicated transactions than simple request/response. The design of SOAP enables the same SOAP message to be received, modified, and forwarded to a different party than from the one it was received. In SOAP terminology, intermediaries perform different roles with respect to the same SOAP message. Some intermediaries may add information; some may delete information; and some may only read existing information all in the due process of fulfilling a service.
The SOAP Message Security specification describes how one or more signatures can be applied and validated to ensure the full security of the SOAP message as it travels from the initiator, through the intermediaries, and the ultimate relying party. Figure 1 illustrates a SOAP message as it is transformed from point to point. In the figure, the originator creates a SOAP message and applies a signature (SigORIG) that signs Parts 1 and 2. An intermediary captures the message appends a new part (Part 3), adding its own signature (SigIM) to cover parts 2 and 3 (by counter-signing Part 2, it may be indicating that it has reviewed and approved it). The message then goes to the relying party who verifies both signatures.
Besides signing parts of a SOAP message dealing with the execution of the service, the SOAP Message Security specification also defines the signing of security tokens and references to security tokens within SOAP messages. With regard to the latter, the SOAP Message Security specification defines a special transform that allows an XML Signature to point to a security token reference but actually sign the referenced object, not the reference. Hence, service-oriented environments have the flexibility of signing the security token reference itself, the object pointed to by the security token reference, or doing both.
Compliance
Both SOAP and SAML have features supporting compliance to rules regarding processing and policies. An (optional) feature of SOAP Message Security of particular value to service-oriented environments where compliance is a priority is the ability of a requester to require that a responder provide evidence in the response that the responder validated the signature in the request. This is so that the requestor can be confident that the response is based on unaltered information sent by the requestor. The feature, called SignatureConfirmation, does not disallow intermediaries from modifying non-protected parts of the SOAP message as long as those intermediaries do not maliciously or accidentally modify parts of the SOAP message signed by the requestor.
In SAML, XML Signatures are used to authenticate and protect the integrity of both requests (e.g. a request for an authentication assertion) and responses (an authentication assertion). The SAML specification states that if a SAML assertion contains an XML Signature, then the relying party must not trust the SAML assertion unless the XML Signature is valid. If the signature is valid, the relying party may then assess “the identity and appropriateness of the issuer and may continue to process the assertion in accordance with this specification and as it deems appropriate”.
SAML also uses signatures for signing the Consent attribute. The Consent attribute indicates whether or not the consent of the principal (the one whom the assertion is about) was obtained or not by the issuer of the message (either a request or response) and under what conditions. As examples of consent, consider a service that would like to obtain an assertion from an identity provider about an attribute of a user. The service may need, due to internal privacy policies or government regulations, to obtain the consent of the user before querying certain information about that user. As well, the user's identity provider may need to obtain the consent of the user before providing that information.
Need for Message-Level Security
Other message-level security formats such as PKCS#7 which are not XML-aware do not inherently have the capability of selectively signing and encrypting message parts for different audiences. PKCS#7 does, however, at least provide unbroken message-level security between the originator and the relying party. In contrast to the message-level security provided by XML Signature, XML Encryption, and PKCS#7, is TLS which operates at the transport layer. For direct server to server communication that does not require application-aware, process-aware, policy-aware, auditable, provable security, TLS is sufficient. In the world of SOA, however, one needs end-to-end security that can be tailored to the specific, dynamic needs of enterprises and their applications; and that is historically auditable in order to prove compliance with the internal and external regulations. That kind of higher-level security requires message-level security.
Need for Speed
In a service-oriented environment, message-level security requires access to the public key material of the constituent organizations. This means that there must be a secure, up-to-date repository of the public keys and a highly efficient means of accessing the public keys in that repository. However the nature of service-oriented environments is that they are distributed (often over a wide geographic area), may contain mobile clients, and yet, because the services are intended to enable machine-to-machine communication, high performance is a necessity. And that means that message-level security too must be of the highest performance or else it will be a bottleneck to the system's primary functionality.
The IAM Trust Authority System
The Trust Authority System from IAM Technology is a hardware appliance that incorporates breakthroughs in cryptographic research made at Brown University for the United States Department of Defense. Specifically, the Trust Authority System enables fast and easy distribution of validated public keys in distributed, federated environments such as those built on SOA using SAML and SOAP-based Web Services. It does so by allowing relying parties to efficiently interact with validation responders. A validation responder is an authenticated dictionary widely distributed throughout Layer 7, and among partner organizations. Validation responders reply to queries about the validity of a public key in real time (tested to 54 micro-seconds) locally. An answer from a validation responder can be trusted as if it came from a source. Validation responders can even issue trust in untrusted environments.
These features distinguish the IAM Trust Authority architecture:
• Trust domains can easily update their public key material through XKMS (XML Key Management Specification) messages to the IAM Trust Authority;
• The IAM Trust Authority can efficiently and securely push updates to validation responders throughout a service-oriented environment; and
• The validation responders can provide near-instantaneous, verifiable responses to public key requests from applications.
Dynamic Membership
In a dynamic, federated environment, new members enter and existing members may leave. As members come and go, so must the status of their public keys within the environment.
The X10 Trust Authority architecture makes management of a dynamic membership easy through its straightforward XKMS interface for registering, reissuing, and revoking the public keys securely stored within the X10 Trust Authority. What is unique about the Trust Authority is how it then updates the information base of the validation responders. Through the STMS update mechanism, the IAM Trust Authority can update multiple validation responders using very little bandwidth and requiring minimal processing power internally and within the validation responders. This makes it possible for the organizations within a service-oriented environment to be assured that the relying parties in that environment have the best possible access to up-to-date trust information.
Historically Provable Validation of the Public Key
Compliance requires evidence. In the area of signature validation, one needs evidence that the public key used to validate signature was valid at the time that the validation occurred. As mentioned in the previous section, participating organizations within the service-oriented environment join, leave, or simply update their keys. Yet how can one know whether a particular public key was valid at the time signature was verified?
To do this, the IAM Trust Authority incorporates each update into the existing authentication dictionary in accordance with IAM’s Persistent Authenticated Dictionary (PAD) technology. With PAD, each update to the authenticated dictionary results in an adjunct to the data structure along with a corresponding Basis. To accommodate the time dimension of PAD, the STMS queries for historic validation include an additional parameter for the time instant of interest and the returned answer proofs are similarly cryptographically dependent on the time instants of the corresponding updates to the status of the public key. Consequently, the validation status of a public key can be proved for any time instant and, as such, that proof can be used as evidence for compliance with respect to signature processing and therefore also with respect to identity-related assertions and Web Services transactions.
Real-time Public Key Validation
As mentioned earlier, dynamic, federated, service-oriented environments cannot be bottlenecked by security. Indeed, many of them are incorporating in-line hardware appliances to realize wire-speed processing of secured SOAP and SAML messages.
Whether signature validation is done in hardware or software, doing it efficiently requires real-time responses to public key validation queries. The IAM Trust Authority architecture makes that possible. The high efficiency of an IAM Trust Authority-based deployment is possible because the placing of the validation responders can be optimized for the particular resident infrastructure as the validation responders need not be secured. This is possible thanks to the use of a unique data structure (called a skip list) that enables efficient updating of distributed validation responders and a corresponding cryptographic mechanism that provides trusted proofs to relying parties about the answers received from a validation responder. With the IAM Trust Authority Architecture, system components within a service-oriented environment can now have up-to-date validation status for public keys, and access to those keys, in real time.
Conclusion
Collaboration among enterprises, or within the constituent organizations of a single large enterprise, is being realized today through service-oriented architecture – much of which is being implemented with SOAP-based Web Services to enable advanced communication among devices and with SAML to ensure that participants in the transaction are identified, authenticated, and authorized.
SOAP and SAML, and their respective security specifications, contain many features that are invaluable to implementing multi-party business processes and ensuring that those processes are conducted in compliance with security policies, privacy policies, internal policies, and government policies. These features are designed to be best secured with message-level security; however, message-level security in a service-oriented environment requires real-time public key validation. Now, with the IAM Trust Authority, real-time public key validation is a reality thanks to its implementation of IAM’s advanced cryptographic research. Furthermore, the revolutionary technology behind the IAM Trust Authority architecture supports dynamic membership among the participating enterprises and provides cryptographically provable evidence about the validity or not of a specific public key for future compliance audits.
Subscribe to:
Posts (Atom)
