scalable and usable attribute mappings in keystone - openstack

7
Scalable and Usable Attribute Mappings David Chadwick University of Kent

Upload: davidwchadwick

Post on 16-Jul-2015

96 views

Category:

Internet


2 download

TRANSCRIPT

Page 1: Scalable and usable attribute mappings in Keystone - Openstack

Scalable and Usable Attribute Mappings

David Chadwick

University of Kent

Page 2: Scalable and usable attribute mappings in Keystone - Openstack

How Many Are There?

• Millions of potential IdPs (cf LDAP directories)

• Billions of potential identity attributes (cfdifferent variants of LDAP attributes)

• How to manage this in a simple, scalable, easy to use, trustworthy way?

Page 3: Scalable and usable attribute mappings in Keystone - Openstack

3 FiltersIdPs

TrustedIdP filter Trusted

Attributefilter

Trusted Attributesfrom Trusted IdPs

MappingRulesfilter

KeystoneAttributes

Attributes fromTrusted IdPs

Page 4: Scalable and usable attribute mappings in Keystone - Openstack

Net Effect

• Gives the administrator must better and finer control

• Much easier to specify mapping rules (which can be complex)

• Don’t need to worry about unknown attributes and regex matches on them

• Simpler and less complex mapping rules

Page 5: Scalable and usable attribute mappings in Keystone - Openstack

Simple Example• Suppose you trust 3 IdPs

– Trust IdP 1 to issue attributes a and b– Trust IdP 2 to issue attributes a and c– Trust IdP 3 to issue attributes a, b and c

• With existing scheme you need 3 largish mapping rules– IdP 1: a maps to g1, b maps to g2– IdP 2: a maps to g1, c maps to g3– IdP 3: a maps to g1, b maps to g2, c maps to g3

• With proposed scheme you need 3 simpler rules– a maps to g1– b maps to g2– c maps to g3

• Along with 3 trusted attribute rules– Trust IdP1 to issue a and b– Trust IdP2 to issue a and c– Trust IdP3 to issue a, b and c

Page 6: Scalable and usable attribute mappings in Keystone - Openstack

What about Large Federations?

• The current mapping rules are even worse.– E.g. UK AMF has over 100 IdPs who all issue the same set of EduPerson

Schema attributes

• This will require >100 almost identical rules– IdP 1: a maps to g1, b maps to g2– IdP 2: a maps to g1, b maps to g2– ……..– IdP 100: a maps to g1, b maps to g2

• Instead of– a maps to g1– b maps to g2– Trust IdP1 to issue a and b– Trust IdP2 to issue a and b– ……– Trust IdP 100 to issue a and b– We may want to allow “Trust All IdPs to issue a and b”

Page 7: Scalable and usable attribute mappings in Keystone - Openstack

Implication

• All attributes must be syntactically and semantically unique in a federation

• But what if attribute a from IdP 1 is syntactically the same as but semantically different to attribute a from IdP 2?– E.g. VP in IdP1 means senior manager, lots of them– VP in IdP2 means 2nd in command, only 1 of them

• Solution – Optionally qualify identity attribute in mapping rule with issuing IdP– IdP1.a maps to g1– IdP2.a maps to g2– b maps to g2– c maps to g3– If IdP is missing it means all IdPs