1. All About Attributes (in federated identity) Nate Klingenstein ndk@internet2.edu 30 January 2007 OGF 19 Chapel Hill

2. All About Attributes Origination Transformation Transport Consumption Practical Guidelines

3. 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

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

5. 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?

6. An Attribute by any other Name… eduPersonAffiliation: staff 1.3.6.1.4.1.5923.1.1.1.10: staff https://middleware.internet2.edu/attributes/eduPers on/eduPersonAffiliation: staff urn:mace:dir:attribute-def:eduPersonScopedAffiliation: staff@supervillain.edu staff@supervillain.edu

7. 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="http://www.w3.org/2001/XMLSchema #string ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:2.5.4.42" FriendlyName="givenName"> By-Tor

8. 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.

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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, http://www.cheapbooks.edu/attributes/ourstudent 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

17. 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

18. 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?

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

20. 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

21. Question for You gridPerson?

22. Any Questions? Nate Klingenstein ndk@internet2.edu