Moonshot Workshop14th October 2014

Introduction to the DayMoonshot Workshop

Agenda

10:00 – 10:10 Intro to the morning10:00 – 11:00 Pseudonymous identifiers, account mapping11:00 – 11:15 Break

11:15 – 12:30 Your requirements12:30 – 13:30 Lunch

13:30 – 13:40 Intro to the afternoon13:40 – 14:30 Management Portal14:30 – 15:30 Open questions / assistance15:30 – 15:45 Break

15:45 – 16:00 Summary

Moonshot & Communities

• A quick reminder… What are communities?

Communities and Policy

Authentication Policy Community /(Community of Registration)

Community A

Community B

Community C

Organisation validationto APC’s defined standards

Policy coming from communityrequirements. Could include:• Registration LoA• AuthN LoA• Operational Practices• User behaviour• Attribute release (RADIUS

& SAML)• Etc.

Moonshot & Communities

• Communities will consist of a subset of the entities connected to a particular APC.

Whole Trust Network

Community A

Community B

Community C

Moonshot/TR – Pseudonymous Identifiers

• SAML & eduroam roam have one pseudonymous id:– eduPersonTargetedId– CUI

• Allows pseudonymous use of resources – good

• Typically targeted to RP to stop vendor collusion– From privacy perspective – good– From perspective of projects with multiple

resources that want to link accounts – bad!

Moonshot/TR – Pseudonymous Identifiers

• Moonshot has more layers than SAML / eduroam

• Let’s take advantage of that…• Three layers:– Host– Realm– Community

RP1 IdP1 RP2

cardiff.ac.uk

RP1 RP2 IdP1

ja.netCommunity A

RP Targeted Identifier

RP Targeted

abcd

efgh

ijklmno

p

• Different for every RP– No collusion– But no (good) linking

either

RP1 IdP1 RP2

cardiff.ac.uk

RP1 RP2 IdP1

ja.netCommunity A

Realm Targeted Identifier

Realm Targeted

abcd

• Different for every realm– No collusion across realms– Linkability between RPs in

same realm

abcd

efgh

efgh

RP1 IdP1 RP2

cardiff.ac.uk

RP1 RP2 IdP1

ja.netCommunity A

Community Targeted Identifier

Community Targeted

abcd

• Different for every community– No collusion across

communities– Linkability between RPs in

same community

abcd

abcd

abcd

Pseudonymous Identifiers

• Wiki contains (or will do) instructions on how IdPs can enable this:– FreeRADIUS policy.d file– Currently hash based generation– Will also support stored (and revokable) option

Account Mapping / AuthZ

• Two/three/four main options:– IdP has control:

• IdP asserts info (e.g. mailbox name), RP uses that info to map directly to account

– RP has control:• IdP asserts info (e.g. pseudonymous id (in RADIUS or

SAML)):– RP Proxy uses that info to map to account, with transformational

logic– RP Proxy passes info unmodified, and service itself uses its own

stuff to map to account– RP Proxy passes info after transformation, and service itself uses

its own stuff to map to account

Existing vs JIT account

• Existing accounts:– Use realm/COI wide identifier to get people to

register online first and create and account linked to that id

– Or create account in advance, get IdP to assert that info for each user

• JIT– Could get FR to run custom command to create

something on the fly– Or app/service may be able to do this itself

DEMO

Final Q&A

• Any questions?

THANK YOUJanet, Lumen House

Library Avenue, Harwell Oxford

Didcot, Oxfordshire

t: +44 (0) 1235 822200

f: +44 (0) 1235 822399

e: service@ja.net