All About AttributesAll About Attributes

(in federated identity)

Nate Klingensteinndk@internet2.edu

30 January 2007

OGF 19 Chapel Hill

All About Attributes

• Origination

• Transformation

• Transport

• Consumption

• Practical Guidelines

What’s 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. (@supervillain.edu)• eduPersonPrincipalName:

magneto@supervillain.edu• eduPersonEntitlement:

urn:mace:dir:entitlement:common-lib-terms– Groups– Privileges

• Email: mace-dir@internet2.edu

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

1.3.6.1.4.1.5923.1.1.1.10: staff

https://middleware.internet2.edu/attributes/eduPerson/eduPersonAffiliation: staff

urn:mace:dir:attribute-def:eduPersonScopedAffiliation: staff@supervillain.edu

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"> <saml:AttributeValue xsi:type="xs:string">

By-Tor</saml:AttributeValue>

</saml:Attribute>

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

What’s 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

<Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="_b9d9777ac0b78d5b3b820e1eef63e275" IssueInstant="2007-01-29T19:20:05.716Z" MajorVersion="1" MinorVersion="1" ResponseID="_ba0e957d89d6f63ec8154ab962183eb4" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><Status><StatusCode Value="samlp:Success"/></Status><Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_631d3b6cd865fa9cd5b101899fa8e157" IssueInstant="2007-01-29T19:20:05.716Z" Issuer="https://idp.testshib.org/shibboleth/testshib/idp" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2007-01-29T19:20:05.716Z" NotOnOrAfter="2007-01-29T19:50:05.716Z"><AudienceRestrictionCondition><Audience>https://sp.testshib.org/shibboleth/testshib/sp</Audience><Audience>urn:mace:shibboleth:testshib</Audience></AudienceRestrictionCondition></Conditions><AttributeStatement><Subject><NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="https://idp.testshib.org/shibboleth/testshib/idp">_9a46e887ae1bad9d81e25a8b1b12d819</NameIdentifier></Subject><Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonEntitlement" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue>urn:mace:dir:entitlement:common-lib-terms</AttributeValue></Attribute><Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonScopedAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue Scope="testshib.org">Member</AttributeValue></Attribute><Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue>Member</AttributeValue></Attribute><Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonPrincipalName" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"><AttributeValue Scope="testshib.org">myself</AttributeValue></Attribute></AttributeStatement></Assertion></Response>

Sometimes also in between: Third Parties

• Many forms already on campus; when it’s all in the family, it’s just metadirectories & provisioning– Data Warehousing– Central Directories/Databases

• Proxies– What NAT’s 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 can’t be revealed• Metadata can help

2. Decide on common protocols & bindings3. 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 isn’t 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

Example #1

• System of record: SIS• Attributes needed:

eduPersonScopedAffiliation• Other information needed:

• Check issuer against attribute scope so OSU can’t 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• 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

Guiding Principles

• Attribute-enable applications

• Be pragmatic and trusting– Because it’s 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

ndk@internet2.edu