1 / 22

All About Attributes

All About Attributes. All About Attributes (in federated identity). Nate Klingenstein ndk@internet2.edu. 30 January 2007 OGF 19 Chapel Hill. All About Attributes. Origination Transformation Transport Consumption Practical Guidelines. What’s an Attribute?.

avent
Télécharger la présentation

All About Attributes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. All About Attributes 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. 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

  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.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/eduPerson/eduPersonAffiliation: staff urn:mace:dir:attribute-def:eduPersonScopedAffiliation: 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"> <saml:AttributeValue xsi:type="xs:string"> By-Tor </saml:AttributeValue> </saml:Attribute>

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

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

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

  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 • Determine who needs to know what, who can say what, and what can’t be revealed • Metadata can help • Decide on common protocols & bindings • Check whether someone has already defined an attribute name/value space that meets your needs • If so, use it; if not, name your attribute wisely and constrain values if necessary • 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 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

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

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

  21. Question for You • gridPerson?

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

More Related