The document discusses REFEDS' interest in facilitating identity federations through central registration of entity data and legal agreements. It notes the current barriers federations face, like multiple registries of entity data, legal documents, and fees. It proposes that REFEDS could help by providing a central place for registering this information, similar to its PEER service which allows cross-federation entity registration and discovery. This would help reduce complexity for service providers joining multiple federations.

1. What is REFEDS Interested In?
Nicole Harris
UK Access Management Focus, JISC Advance
@nicoleharris
Slides: http://www.slideshare.net/nicolevharris

2. Me
• UK Access Management Focus;
• Advisor to UK federation;
• REFEDS Coordinator;
• PEER Project Manager;
• Shibboleth Consortium Manager;
• Generally opinionated about access and identity.

3. What does the R&E Federation space
look like?

4. R&E Federations Status (1)

5. R&E Federations Status (2)
• 27 Federations plus 2 confederations.
• 4753 entities within those federations.
• 1815 Identity Providers.
• 2755 Service Providers.
• Plus several ‘others’ (don’t worry about it).
(November 2011)

6. Top resources?
• In 14 federations:
– Czech Medical Atlas and Microsoft Dreamspark.
• In 12:
– Web of Knowledge, Scopus, ScienceDirect.
• In 11:
– IEEE, EBSCO.
• In 10:
– Springer, OVID.

7. So it’s all working, right?

8. For SPs, Federation Sucks
I know because I wrote a paper on it!

9. Barriers
• Multiple registry of entity data.
• Multiple legal documents.
• One-off clauses.
• Interpretation of data protection.
• Sponsorship letters.
• Fees.
• Technical Barriers.
https://refeds.terena.org/index.php/Barriers_for_Ser
vice_Providers

10. Registering Entity Data
• Federations are just big metadata (xml) files.
• Entity = your chunk of that data.
• It goes a bit like this:

11. How does it work?
Federation A
Federation B
You
Federation C

12. What we need is a place where this
can be centrally registered and then
called on by federations…

13. PEER
http://beta.terena-peer.yaco.es/

14. Legal Contracts
F ED
ERA
T IO
T he
N RU L
A
fr am u st r al
e ia
t r u st w o r k an n A cc e
ES
e ss F
w it h d el ect d su p p ed e
r at
in an r on o
in st d b ic co r t in fr as io n p r
it u t
io n s et w een m m u n t r u ct o vi d e
TERMO DE COMPROMISSO PARA ADESÃO À FEDERAÇÃO CAFe ic at u sa
T h is in A u
u st r n iv er si io n r e t o fa
d al ia t ies s an d ci
t o b o cu m e an d an d co ll li t at e
em nt o o ve r ab
ser vi et u t li r se as e se ar ch o r at io n
ce p b y p ar nes
th .
Pelo presente, a organização identificada neste Termo, ora denominada PARTICIPANTE, r o vi
d er
t ic ip
at in e r u les
T h is s. g id an d
adere a este documento e assume a responsabilidade pela utilização dos serviços d o cu en t o b li
Par it y
disponibilizados pela Comunidade Acadêmica Federada, doravante denominada t icip m en t an d gat io
an t s su p ns
simplesmente CAFe, ciente da “Política de Uso da Federação CAFe: provedores de e r se
serviço”, e da “Política de Uso da Federação CAFe: provedores de identidade”,
24 M d es
t he
ay 2 Fed
conforme adiante descrito. 011 er at
io n
Ru le
s fo
r
PARTICIPANTE: [nome da instituição], com sede na [endereço], neste ato representada
por [nome completo], [função], doravante denominada [sigla da instituição]
O presente Termo considera que:
a) A Federação CAFe é composta por um conjunto de instituições que, sobre uma
infraestrutura de autenticação e autorização multidomínios, estabelece uma rede de
confiança que simplifica o acesso a serviços federados oferecidos;
b) A RNP tem como atribuição o gerenciamento dos processos de disponibilidade,
confiabilidade e melhoria continua do Serviço da CAFe, além de apoiar a
homologação visando a adesão de novos Provedores de Identidade e Provedores de
Serviço na federação CAFe, bem como o suporte a atualizações e melhorias
contínuas;
c) a RNP e a PARTICIPANTE têm interesse comum na manutenção e desenvolvimento
da Federação CAFe com o objetivo de simplificar o processo de Autenticação e
Autorização entres as instituições participantes; ©A
ustr
alian
Acces
d) a PARTICIPANTE tem interesse em integrar a Federação CAFe como Provedor de s Fe
dera
[Identidade ou Serviço], para benefício da comunidade de educação, pesquisa e tion
RedIRIS Identity Service Conditions of Use for Identity Providers Inc.
cultura.
Para tanto, a PARTICIPANTE dá ciência e se compromete ao que se segue: RedIRIS Identity Service
Conditions of Use for Identity Providers
1 - DO OBJETO
Version 1.0 – 20080220
1.1 – O presente Termo tem por objeto estabelecer as diretrizes de participação, a serem
realizadas com o apoio recíproco, na CAFe;
___________________________________________________________________, as applicant for
1 the identity transfer services provided by the RedIRIS Identity Service (SIR), to be used by the identity
provider identified by its URL, unique ID, and public key included at the end of this document
(referred in the rest of this document as “the Applicant”) declares that:
1. Knows and accepts the rules, procedures and technical requirements for the connection of
their identity management system with the RedIRIS Identity Service, as specified at
http://www.rediris.es/sir/. Applicants accept the appropriate changes that may take place, and
that shall be communicated with sufficient time through the service website, and directly to the
UK Access Management Federation for RedIRIS Official Liaisons (“Personas de Enlace con RedIRIS”, referred as “PERs” in the rest
of this document) of the corresponding affiliated institution.
Education and Research
2. Knows that breaking these conditions can imply the discontinuation of the service.
3. Declares that data included in this document are accurate, apart error or omission in good
faith.
Rules of Membership 4. Commits to permanently update the information included in this document, informing the
PERs of any change that takes place.
5. Assumes that RedIRIS, in all procedures related to service provision, will act according to the
data provided in this document.
6. Knows and accepts that any falsity or error in the data included in this document can be
1st August 2011 cause of the discontinuation of the service.
7. Knows and accepts that once the service is active it can be revoked in case of violation of the
requirements.
8. Knows and assumes that the service can be revoked in case of serious technical negligence.
9. Declares that, according to their best knowledge, the connection of the identity provider
identified below with the RedIRIS Identity Service does not harm the rights of any third party.
10. Knows and accepts that the service is provided by RedIRIS in non-commercial terms for its
users in the research and academic community, and that RedIRIS shall not be held liable for
any damage caused, directly or indirectly, by the usage of the service.
11. Knows and assumes that RedIRIS will perform personal data processing according to Ley
Orgánica 15/1999 on Personal Data Protection and the regulations developing it.
12. Knows and assumes that the rights to access and rectification can be exercised according to
the above mentioned regulations. The rights to cancellation and opposition can only be
exercised after the discontinuation of the service, since personal data processing by Red.es is
required for the use of the RedIRIS Identity Service.
Version 2.1
ST/AAI/UKF/DOC/001
1/2

15. Wouldn’t it be great if these were
standardised and simplified?

16. REFEDs Policy Review
• Painstakingly taking apart every clause in
every federation policy.
• Mapping these to generic content ‘blocks’ and
‘elements’ within each block.
• Making recommendations about structure
and unnecessary language.
• NOT a legal review.

17. Isn’t there an easier way?

18. Full Interfederation
• The ability of federations to exchange
metadata about their entities.
• Normally an additional legal agreement
between the 2 federations.
• Full technical and policy integration.
• Bi-lateral (UK and Edugate) or via groups
(eduGain and Kalmar2).

19. eduGain (1)
www.edugain.org

20. eduGain (2) – Drawbacks
• At least one of the federations you are a
member of needs to have signed up for
eduGain.
• Opt-in: you have to ask to be included in an
aggregate.
• Not always clear which entities are
interfederated – are your customers there?

21. eduGain (3) Benefits
• Only have to have a relationship with 1
federation.
• Technically, as an SP, you can chose with
federation that is.

22. A quick note on Barriers to Users

23. Login Interfaces Suck
I know this because I’ve tried to use them

24. How Bad?

25. New UK federation WAYF

26. Foodle and DiscoJuice

27. MDUI
• Currently being used by DiscoJuice and
Shibboleth Embedded Discovery Service /
Central Discovery Service.
• OASIS Standard for IdP Discovery:
– http://docs.oasis-
open.org/security/saml/Post2.0/sstc-saml-idp-
discovery.pdf.

28. MDUI for SPs (Shibboleth Recs)
Non Logo elements
• <mdui:DisplayName>Recommended required
<mdui:Description>Recommended 100 chars max
• <mdui:Keywords> Not used
• <mdui:InformationURL> Available
• <mdui:PrivacyStatementURL> Available
Logo elements
• Shibboleth - must be specified using an HTTPS URL
• Shibboleth - logo size should be between 64px by 350px wide and
64px by 146px high
• Shibboleth - logos should have transparent backgrounds
• Shibboleth - logos look better if they have a landscape rather than a
portrait aspect ratio
https://refeds.terena.org/index.php/MDUI_-_Software_recommendations

29. MDUI for IdPs (Shibboleth Recs)
Non Logo elements
<mdui:DisplayName>Recommended, 33 chars max Strongly recomended <mdui:Description>
Supporting the Display Name function with more details
<mdui:Keywords> Used Used for incremental search
<mdui:InformationURL> Not used at present
<mdui:PrivacyStatementURL>Not used at present – see Attribute WG recs
<mdui:IPHint>Not used Planned for future release
<mdui:DomainHint> Not used Planned for future release
<mdui:GeolocationHint> Not used Heavily used. Strongly recomended.
Logo elements
• Shibboleth - The URL specifying the logo must be https protected.
• Shibboleth - One logo should be provided of size approximately 80px(width) by 60px (height). A
larger logo may be provided but the aspect ratio should be maintained (logos are selected based on
apsect ration).
• Shibboleth - One logo should be provided of size 16px by 16px.
• Shibboleth - Logo backgrounds should be transparent.
https://refeds.terena.org/index.php/MDUI_-_Software_recommendations

30. Thank you for listening