Appropriate Access InCommon Identity Assurance Profiles David L. Wasley Campus Architecture and Middleware Planning workshop February 2008

Outline Access and Identity Identity Assurance InCommon Identity Assurance Profiles

Access and Identity Modern distributed IT environments separate identity and access management “single sign on” binds an identifier to a physical person Necessary information about that person is given to resource access management systems that need it autheNtication vs authoriZation Why identity is important to security Security is not just about building moats & walls You’d like to locate the person who does a bad thing Strong identity assurance also should help protect people against ID theft

Access and Identity Modern distributed IT environments separate identity and access management “single sign on” binds an identifier to a physical person Necessary information about that person is given to resource access management systems that need it autheNtication vs authoriZation Why identity is important to security Security is not just about building moats & walls You’d like to locate the person who does a bad thing Strong identity assurance also should help protect people against ID theft

Access Models Authorization determines access to resources Policy + process + mechanism + enforcement... Access Control List of specific persons Requires specific identifier for each user Access rules, based on group attributes E.g., any “member of the campus community” Access may also be based on parameters, e.g., resource availability, time of day, location of user, etc... Access decision is made by resource manager

Identity Model Identity is the set of information about a person Unique attributes, e.g., biometric, U.S. President,... Group attributes, e.g., student, male, Joe Smith,... Pseudonymous attributes, e.g., the same person as before Three parties involved Identity Subject is a person who wants to assert an ID Relying Party, e.g. Service Provider, trusts identity information received from an Identity Provider Identity Provider agrees to support identity Subjects by maintaining a database or directory of reliable ID data Each party must trust the others

Identity Model (cont.) Digital credential is bound to a physical person May, but need not, contain some identity information Different credential technologies for different purposes Binding achieved through a registration process RA process must find existing record or create a new one Credential S/N is index to Identity Mgmt DB Credential S/N need not be same as Subject identifier Relying Party uses IdM DB information as part of decision about access to services or resources How good is a Provider’s assertion of an identity?

Identity Assurance How reliable does an identity need to be? Depends on what’s at stake, consequences & mitigations Relying Party needs to do the risk analysis How much can a RP trust an identity assertion? What identity? Does the RP trust the IdP as an organization? How well was identity established and maintained? How (and when) did the Subject authenticate to the IdP? If something goes wrong, can the Subject be found? Nothing is absolute; it’s all degrees of certainty

Identity Assurance Projects NIST Federal eAuthentication See also HSPD-12 and NIST FIPS 201 Liberty Alliance Identity Assurance Framework RealID “Final Rule” FBI National Biometrics Database InCommon Verified Identity Profiles ‡ “Bronze”, “Silver”, … profiles ‡ Temporary name

InCommon Identity Assurance Profiles Now in DRAFT and may change … Structured sets of requirements intended to satisfy management of access to general classes of resources Not necessarily hierarchical Hopefully limited in number(!) First two defined to be equivalent to eAuth “Bronze” == eAuth levels 1 “Silver” == eAuth level 2

Identity Assurance Assessment Framework Business, Policy and Operational Factors Registration and Identity Proofing Digital Electronic Credential Technology Digital Electronic Credential Issuance and Management Security and Management of Authentication Events Identity Information Management Identity Assertion and Content Technical Environment

InCommon “Silver” Profile Business, Policy and Operational Factors Established legal entity Designated authority for IdMS & IdP General Disclosures to identity Subjects Documentation of policies & practices Appropriate staffing Subcontracts Helpdesk Audit of IdMS operations Risk Management plan Logging of operation events

InCommon “Silver” (cont.) Registration and Identity Proofing Identity Verification Process disclosure Retain records of Id documents And one or more of: Confirmed relationship with the organization In-person proofing Remote proofing Digital Electronic Credential Technology Unique credential identifier Subject modifiable shared secret Strong resistance to guessing shared secret *

InCommon “Silver” (cont.) Credential Issuance and Management Unique Subject identifier Credential status Confirmation of delivery Credential verification Suspected credential compromise (†) Credential revocation † indicates an InCommon variant from the NIST recommendations

InCommon “Silver” (cont.) Security and Management of Authentication Events End-to-end secure communications * Proof of control Session authentication Stored secrets Protected secrets Mitigate risk of sharing credentials Threat protection * Authentication protocols *

InCommon “Silver” (cont.) Identity Information Management Identity status management Identity Assertion and Content eduPerson attributes (†) Identity Assertion Qualifier (†) Cryptographic security Technical Environment Configuration Management Network Security Physical Security Continuity of Operations (†)

Implementation Notify InCommon of intention to qualify Assessment by independent (internal) auditor Auditor writes summary letter for InCommon Execute Addendum to Participation Agreement InCommon adds Identity Assurance Qualifier(s) to IdP metadata IdP then may include IAQ(s) in assertions Is responsible to ensure they are appropriate Technical implementation yet to be determined

Use of InCommon IAQs IAQ represents a profile, not a level A given IdP can support multiple profiles IdP may assert InCommon IAQ(s) only if assigned to it by InCommon Identity assertion may contain multiple IAQs E.g., “Bronze” or both “Silver” and “Bronze” Avoids implying hierarchy and allows for additions with minimal disruption Relying Party looks for an IAQ it will accept

Further Information InCommon Identity Assurance Profiles David Wasley NIST Liberty Alliance Identity Assurance Framework RealID FBI biometrics database