All About Attributes (in federated identity) Nate Klingenstein 30 January 2007 OGF 19 Chapel Hill

All About Attributes Origination Transformation Transport Consumption Practical Guidelines

Whats an Attribute? Most attributes are atoms of information –At least one name Sometimes more… Often unique per protocol –At least one value Sometimes more… –May include other bits, like scope or nesting Practically anything can be stuffed into this structure –But all parties need to understand it The data surrounding an attribute are as important as the attribute itself

Some Useful Attributes CN(common name): Nate Klingenstein DN(distinguished name): C=, O=, OU=… eduPerson(Scoped)Affiliation: student, staff, faculty, etc. eduPersonPrincipalName: eduPersonEntitlement: urn:mace:dir:entitlement:common-lib-terms –Groups –Privileges

Who Makes Attributes? X.520 eduPerson (MACE/Internet2/EDUCAUSE) Your applications Your favorite corporate suite Your friendly local federation Your service provider Your identity provider You?

An Attribute by any other Name… eduPersonAffiliation: staff : staff on/eduPersonAffiliation: staff urn:mace:dir:attribute-def:eduPersonScopedAffiliation:

An Attribute by any other Name… <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0: profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0: profiles:attribute:LDAP" xacmlprof:DataType=" #string ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid: " FriendlyName="givenName"> By-Tor

In the Beginning… Attributes originate at a system of record –Database, directory, student information system, virtual organization, etc. –The ultimate (digital) authority Everything really starts with people –I&A –Credentialing –Data entry –Governments, corporations, organizations, other users, self-asserted, etc.

At the End Everything distills to an action by the SP Final attribute format desired may vary –Set of name/value pairs –Boolean –Something more complicated XACML? Structured XML? Issuance information required may vary The SP is always a PDP and the PEP –And has ultimate control

How Applications Get Them Shibboleth 1.3 –Individual attributes exported as HTTP Header variables according to AAP.xml –Attribute assertion may also be exported Shibboleth 2.0 –Apache SP Individual attributes exported as subprocess environment variables according to…? Assertions available through (chunking? Localhost?) –Java SP Individual attributes and assertions stored as attributes of the session object Commercial product approaches will vary

Whats in Between? Issuers and Consumers Assertions –Attributes can be contained in and depend on them –Provide context and meaning for attributes Authentication –Both end user and server –Relative, not absolute Protocols, Bindings, Requests/Queries All to support movement, transformation, and use by the SP from the system of record

SAML 1.1 Attribute Assertion http s://sp.testshib.org/shibboleth/testshib/sp urn: mace:shibboleth:testshib _9a4 6e887ae1bad9d81e25a8b1b12d819 urn:mace:dir:entitlement:common-lib- terms Member Member myself

Sometimes also in between: Third Parties Many forms already on campus; when its all in the family, its just metadirectories & provisioning –Data Warehousing –Central Directories/Databases Proxies –What NATs do for IP… Portals Scope vs. Issuer ID-WSF –Attribute aggregation –Delegation –Client issuance Provider/User Agent Convergence

Conservation of Information Information is inevitably destroyed –Where did this attribute originate? –What chain did it traverse to get to me? –Who was trusted along the way? –What other parameters is this attribute based upon? Successful user authentication Successful server authentication Privacy and secrecy vs. knowledge –Your use cases may vary, but you should know how much you know Level of Assurance Grist

Practical Approach 1.Determine who needs to know what, who can say what, and what cant be revealed Metadata can help 2.Decide on common protocols & bindings 3.Check whether someone has already defined an attribute name/value space that meets your needs 4.If so, use it; if not, name your attribute wisely and constrain values if necessary 5.Populate if needed; set release and access control policies

Example #1 A store wants to sell discount books and school shirts to university students Who, exactly, is a student? How precisely do you care? The university and store collaborate to craft the trust agreement If eduPersonScopedAffiliation isnt good enough, or an eduPersonEntitlement The university provisions the attribute to eligible users Attribute information is released to the store, which maintains attribute-based access control Beats accounts and IP Addresses

Example #1 System of record: SIS Attributes needed: eduPersonScopedAffiliation Other information needed: Check issuer against attribute scope so OSU cant buy Florida shirts? Access control rule: require scopedaffiliation *.edu

Example #2 A consortium of scientists from eighteen different universities is collaborating to devise a mind- control TV channel, forming the MCTV WG Re-use institutional identifiers & authentication via a VO They collectively purchase grid cycles for brain wave analysis from a third party cluster The VO wants to audit resource use by member Who speaks authoritatively for which information? Issuer/scope duality Conservation of information Who needs to know what?

Example #2 Systems of Record: Enterprise Directory(via HR), VO database Attributes needed: eduPersonPrincipalName Other information needed: weeeeelll… How do you aggregation your attributes? Access control is usually done inside the application for better error handling

Guiding Principles Attribute-enable applications Be pragmatic and trusting –Because its easy to audit and punish The more common attributes, the more powerful federated identity is –Recycle, reduce, re-use Name everything properly Use strings whenever possible –Applications and people seem to like them Keep flows as simple as possible

Question for You gridPerson?

Any Questions? Nate Klingenstein