How to Survivethe Zombie Apocalypse

Ian A. YoungSDSS, EDINA, University of Edinburgh

ian@iay.org.uk

FAM10, Cardiff, 06-Oct-2010

From an image by Watt_Dabney on Flickr, licensed CC-BY-SA 2.0

Quick AnswerBuy this book

How to SurviveInterfederation

Ian A. YoungSDSS, EDINA, University of Edinburgh

ian@iay.org.uk

FAM10, Cardiff, 06-Oct-2010

What to expect

• Interfederation recap

• How to protect yourself

• Understanding trust

• How to benefit

• Understanding interoperability

Interfederation

Alice Bob

Bob’s Request

Alice’s Response

Alice Bob

Alice’s Metadata

Bob’s Metadata

Bob’s Request

Alice’s Response

Publish

Alice Bob

Alice’s Metadata

Bob’s Metadata

Bob’s Request

Alice’s Response

Exchange

Alice Bob

Alice’s Metadata

Bob’s Metadata

Bob’s Request

Alice’s Response

Consume

Federation Metadata

Alice Bob

Alice’s Metadata

Bob’s Metadata

Bob’s Request

Alice’s Response

OracleOracle

Alice Bob

Alice’s Metadata

Bob’s Metadata

Bob’s Request

Alice’s Response

Fed B metadataFed A metadata

Alice BobA B

Fed B metadataFed A metadata

Alice Bob

A B

Register

Fed B metadataFed A metadata

Alice Bob

A B

Exchange

B A

Fed B metadataFed A metadata

Alice Bob

A B

Consume

B A

Fed B metadataFed A metadata

Alice Bob

A B

Bob’s Request

Alice’s Response

B A

Federation Services

Alice

R P

A

RegA

Trust Issues

We're all friends here.

Aaargh!Zombie horde!

Interfederation

Alice Bob“Trust”

Monolithic Trust

Alice Bob

“This is Bob”

“I like Bob”

“Trust”

Alice Bob

“Behaviouraltrust”

“Technicaltrust”

“Trust”

Note, however, that presence in the federation metadata alone should not be taken to imply particular behavioural guarantees. In particular:

• it is the responsibility of each identity provider to establish appropriate policies for attribute release based on their knowledge of individual service providers;

• it is the responsibility of each service provider to decide how much trust to place in the attributes presented by an identity provider based on their knowledge of the individual identity provider.

UK federation TRP section 4

• Review default Attribute Release Policy

• Be selective about what you release

• Assume that default ARP releases to hostiles

• Significant attribute release only to specific entities

• Keyed on entityID

• These are friendlies

IdP Trust Actions

• Don’t assume the truth of claims from all entities

• Assume IdPs are hostile by default

• Accept claims from:

• Known entities (keyed on entityID)...

• ...where you have a specific basis for behavioural trust (friendlies)

SP Trust Actions

• TRP section 4 paraphrased:

• “Treat everything as hostile by default”

• If you already do this, nothing needs to change

• If you don’t, you should review IdP and SP policies

Trust Summary

Interoperability Issues

Data: 01-Oct-2010 00:00:00

250

500

750

1000

1250

Dec 06 May 07 Oct 07 Mar 08 Aug 08 Jan 09 Jun 09 Nov 09 Apr 10 Sep 10

Total Entities

Metadata Size

• Expect to have to handle somewhat more metadata

• Shibboleth 1.3 is not very good at this

• Use something else!

SAML 1.1 vs. 2.0

• In the UK, still many entities only capable of SAML 1.1

• In newer federations, many entities only capable of SAML 2.0

• Best chance of interoperability from software which can do both

• I’m looking at you again, Shibboleth 1.3

Data: 01-Oct-2010 00:00:00

0%

10%

20%

30%

40%

50%

60%

Jan 08 May 08 Sep 08 Jan 09 May 09 Sep 09 Jan 10 May 10 Sep 10

SAML 2 Support

IdP SP

Data: 01-Oct-2010 00:00:00

0

100

200

300

400

500

600

Jan 08 May 08 Sep 08 Jan 09 May 09 Sep 09 Jan 10 May 10 Sep 10

Transition from Shibboleth 1.3

Entit

ies

Shib 1.3 Shib 2.X

Key Material

• Originally, UK federation based on PKIX credentials (<KeyName> elements)

• This doesn’t work for SAML 2.0 encryption

• This doesn’t work cross-federation due to inconsistent trust roots

• If you want to interfederate, make sure you supply embedded key material

• This is an option even for Shibboleth 1.3

<EntitiesDescriptor Name="http://ukfederation.org.uk">

<Extensions> <shibmd:KeyAuthority> <ds:X509Data> <!-- trust root here, as X.509 certificate --> </ds:X509Data> <ds:X509Data> <!-- trust root here, as X.509 certificate --> </ds:X509Data> </shibmd:KeyAuthority> </Extensions>

<EntityDescriptor entityID=”https://sp.example.org/entity”> <SPSSODescriptor> <KeyDescriptor ...> <ds:KeyInfo> <ds:KeyName>sp.example.org</ds:KeyName> <ds:KeyInfo> </KeyDescriptor> </SPSSODescriptor> </EntityDescriptor>

</EntitiesDescriptor>

<EntitiesDescriptor Name="http://ukfederation.org.uk">

<Extensions> <!-- KeyAuthority trust roots ignored --> </Extensions>

<EntityDescriptor entityID=”https://sp.example.org/entity”> <SPSSODescriptor> <KeyDescriptor ...> <ds:KeyInfo> <!-- KeyName still valid but ignored for interfed --> <ds:KeyName>sp.example.org</ds:KeyName> <ds:X509Data> <!-- public key here, as X.509 certificate --> </ds:X509Data> <ds:KeyInfo> </KeyDescriptor> </SPSSODescriptor> </EntityDescriptor>

</EntitiesDescriptor>

Data: 01-Oct-2010 00:00:00

0%

20%

40%

60%

80%

100%

Dec 06 May 07 Oct 07 Mar 08 Aug 08 Jan 09 Jun 09 Nov 09 Apr 10 Sep10

Direct Key Trust Available

IdP SP

Interoperability Summary

• Stop using Shibboleth 1.3 please!

• Deploy software capable of SAML 2.0

• Provide embedded key material

Miscellaneous Interoperability

• Be careful about ePSA values (see TRP 7.1.2.3)

• Sign up to section 6

• Be prepared to stand up and be counted

Questions?