Bernd Oberknapp, UB Freiburg

Präsentation zum Thema: "Bernd Oberknapp, UB Freiburg"—  Präsentation transkript:

1 Bernd Oberknapp, UB Freiburg
Autorisierung und Zugriffskontrolle in Shibboleth: Attribute Definition, Weitergabe, Verarbeitung 2. Shibboleth-Workshop Freiburg, 23. März 2006 Bernd Oberknapp, UB Freiburg

2 Was sind Attribute? Ein Attribut definiert und beschreibt ein konkretes Objekt (Shibboleth: Benutzer). Einem Attribut sind Werte zugeordnet, wobei der Wertebereich eingeschränkt sein kann. Eine Festlegung des Wertebereichs führt zu einem einheitlichen Vokabular, das erst eine einheitliche und präzise Beschreibung ermöglicht. Beispiel: adresse Syntax festgelegt durch RFC 822 Semantik festgelegt durch RFC 1274 Bernd Oberknapp, UB Freiburg

3 Attribute und Shibboleth
Attribute bilden die Grundlage für Autorisierung und Zugriffskontrolle in Shibboleth: Identity-Provider stellen die notwendigen Attribute für ihre Benutzer zur Verfügung. Service-Provider werten die Attribute anhand ihrer Regeln aus und gestatten oder verweigern je nach Ergebnis den Zugriff. Hierfür sind Absprachen zwischen Identity- und Service-Providern notwendig, die durch Verwendung eines einheitlichen Vokabulars vereinfacht werden! Bernd Oberknapp, UB Freiburg

4 Attribute und Datenschutz
Attribute können personenbezogene Daten sein (Beispiel: adresse). Bei Verwendung personenbezogener Daten sind die (EU-) Datenschutzbestimmungen zu beachten! Personenbezogene Daten dürfen nur dann weitergegeben werden, wenn dies für die Erbringung des Dienstes notwendig ist und der Benutzer der Weitergabe ausdrücklich zustimmt. Bernd Oberknapp, UB Freiburg

5 Das Vokabular: Schemata
Schemata legen eine bestimmte Menge von Attributen, die zulässigen Werte und deren Bedeutung fest. Die für Shibboleth verwendeten Schemata basieren üblicherweise auf eduPerson: eduPerson (InCommon) swissEduPerson (SWITCH) funetEduPerson (HAKA) Auch deutschlandweite Föderation wird eduPerson als Basis für den Austausch von Attributen verwenden. Für einen Datenaustausch auf europäischer Ebene könnte SCHAC die Grundlage sein. Bernd Oberknapp, UB Freiburg

6 Der „Shibboleth-Standard“
InCommon hat den Standard vorgegeben: docs/policies/federatedattributes.html Die Shibboleth-Software wird entsprechend vorkonfiguriert ausgeliefert. Internationale Anbieter orientieren sich üblicherweise an diesem Standard. Die meisten Service-Provider kommen dabei mit einigen wenigen Attributen aus! Bernd Oberknapp, UB Freiburg

7 eduPersonScopedAffiliation
Ermöglicht die Zuordnung der Benutzer einer Einrichtung zu einigen grundlegenden Rollen Zulässige Werte: member, faculty, staff, employee, student, alum und affiliate Beispiel: Erste Implementierungen von kommerziellen Anbietern (EBSCO) basierten auf diesem Attribut. Probleme: Semantik ist auf internationaler Ebene nicht wirklich einheitlich festgelegt (Was genau ist z.B. ein student?) Es fehlen wichtige Rollen wie „walk-in patron“. Bernd Oberknapp, UB Freiburg

8 eduPersonEntitlement
Ermöglicht den Austausch praktisch beliebiger Rechteinformationen Zulässige Werte: URI (URN oder URL) Die Bedeutung der Entitlement-Werte muss zwischen Identity- und Service-Providern abgesprochen werden! Absprache auf Föderationsebene oder sogar föderationsübergreifend ist wünschenswert Problem: „eierlegende Wollmilchsau“ Bernd Oberknapp, UB Freiburg

9 eduPersonEntitlement: Beispiele
urn:mace:incommon:entitlement:common:1 oder urn:mace:dir:entitlement:shared:common-lib-terms? Benutzer ist berechtigt, die von der Einrichtung lizenzierten Ressourcen zu nutzen urn:mace:ebsco.com:<EBSCO-Account> Benutzer darf die auf dem <EBSCO-Account> der Einrichtung verfügbaren Ressourcen nutzen urn:mace:aar:entitlement:unist:redi:admin Benutzer der Universität Stuttgart mit Administratorrechten in ReDI Bernd Oberknapp, UB Freiburg

10 eduPersonPrincipalName
Eindeutiger, persistenter Identifier des Benutzers inklusive Domain ("NetID") Beispiel: Sollte aus Datenschutzgründen nur verwendet werden, wenn die Nutzung des Dienstes nicht anonym oder pseudonym erfolgen kann! Anwendungsbeispiel: Schreibender Zugriff auf eine Anwendung (z.B. Wiki oder Forum), bei der der Autor sich zu erkennen geben muss Bernd Oberknapp, UB Freiburg

11 eduPersonTargetedID Eindeutiges, persistentes Pseudonym des Benutzers für einen Service-Provider Ermöglicht die Wiedererkennung des Benutzers (z.B. für personalisierte Anwendungen notwendig), ohne die Identität des Benutzers zu kennen Erschwert das Zusammenführen von Informationen über einen Benutzer seitens der Service-Provider Problem: Die mitgelieferte Implementierung ist nicht für den Produktionsbetrieb geeignet. Bernd Oberknapp, UB Freiburg

12 Attribute generieren: Resolver
Der Resolver des Identity-Providers erzeugt die Attributliste für den gegebenen Benutzer. Shibboleth bietet hierfür einige Standard-Konnektoren: echo, JDBC, LDAP Bei Bedarf können eigene Konnektoren implementiert werden. Beispiele: eduPersonPrincipalName: echo eduPersonEntitlement: JDBC Bernd Oberknapp, UB Freiburg

13 Resolver-Beispiel 1: echo
<SimpleAttributeDefinition id="urn:mace:dir:attribute def:eduPersonPrincipalName" lifeTime="57600" smartScope="uni-freiburg.de"> <DataConnectorDependency requires="echo"/> </SimpleAttributeDefinition> <CustomDataConnector id="echo" class="edu.internet2.middleware.shibboleth.aa attrresolv.provider.SampleConnector"/> Bernd Oberknapp, UB Freiburg

14 Resolver-Beispiel 2: JDBC
<SimpleAttributeDefinition id="urn:mace:dir:attribute def:eduPersonEntitlement" lifeTime="57600" sourceName="getAttributes"> <DataConnectorDependency requires="db1"/> </SimpleAttributeDefinition> <JDBCDataConnector id="db1" dbURL="jdbc:postgresql://host:port/db?param" dbDriver="org.postgresql.Driver" maxActive="10" maxIdle="5"> <Query>SELECT * FROM getAttributes(?,'unifr');</Query> </JDBCDataConnector> Bernd Oberknapp, UB Freiburg

15 Attribute filtern im IdP: ARPs
Die vom Resolver erzeugte Attributliste wird über die Attribute Release Policy (ARP) für den anfragenden Service-Provider gefiltert. Die Filterung erfolgt dreistufig: Site-ARP: einrichtungsweit Group-ARP: auf Gruppenebene User-ARP: benutzerspezifisch Das Ergebnis erhält der Service-Provider in Form einer SAML Attribute-Assertion. Bernd Oberknapp, UB Freiburg

16 ARP-Beispiel: ReDI <Rule>
<Description>ReDI Site-ARP</Description> <Target> <Requester matchFunction="urn:mace:shibboleth:arp: matchFunction:regexMatch"> ^urn:mace:aar:www-(fr|s)\.redi-bw\.de$ </Requester> </Target> <Attribute name="urn:mace:dir:attribute-def:eduPersonEntitlement"> <Value release="permit" matchFunction="urn:mace:shibboleth:arp: matchFunction:regexMatch"> ^urn:mace:aar:entitlement:[a-z]+:redi:[a-z]+$ </Value> </Attribute> <Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName"> <AnyValue release="permit"/> </Rule> Bernd Oberknapp, UB Freiburg

17 Attribute filtern im SP: AAP
Die Attribute Acceptance Policy (AAP) des Service-Providers legt fest: welche Attribute und Attributwerte von welchen Identity-Providern akzeptiert werden wie diese für die Zugriffskontrolle an den Ressource-Manager bzw. die Anwendung weitergegeben werden Bernd Oberknapp, UB Freiburg

18 AAP-Beispiel: ReDI <AttributeRule Name="urn:mace:dir:attribute-def:
eduPersonPrincipalName" Scoped="true" Header="REMOTE_USER" Alias="user"> <AnySite> <Value </AnySite> </AttributeRule> <AttributeRule Name="urn:mace:dir:attribute-def: eduPersonEntitlement" Header="Shib-EP-Entitlement" Alias="entitlement"> <Value Type="regexp">^urn:mace:aar:entitlement:.+$ </Value> Bernd Oberknapp, UB Freiburg

19 Zugriffskontrolle Die vom IdP gelieferten und über die AAP aufbereiteten Attribute bilden die Basis für die Zugriffskontrolle Shibboleth bietet Ressource-Manager für Apache (Apache Access Control über mod_shib) Alternative ist ein eigener Ressource-Manager in der Anwendung: Attribute werden über HTTP-Header an die Anwendung übergeben. Beispiel ReDI: eduPersonEntitlements werden auf ReDI eigene Benutzergruppen abgebildet. Bernd Oberknapp, UB Freiburg

20 ARP-Verwaltung MAMS (Meta-Access Management System, Australien) hat für die Verwaltung der Attribute Release Policies zwei Werkzeuge entwickelt: ShARPE (Shibboleth Attribute Release Policy Editor, Administrationsschnittstelle) und Autograph (Benutzerschnittstelle) (siehe ShARPE und Autograph sollen in Shibboleth 2.0 und Shibboleth 1.3d integriert werden! Bernd Oberknapp, UB Freiburg

21 ARP-Verwaltung: ShARPE
Service-Provider definieren per XML-Dateien, welche Dienste sie anbieten und welche Attribute für die Nutzung notwendig sind. Identity-Provider können die Definitionen importieren und festlegen, welche Attribute für welche Benutzer standardmäßig freigegeben werden sollen. Damit wird auch definiert, wie die Attribute des Identity-Providers (einrichtungsspezifisch) auf die vom Service-Provider erwarteten Attribute abgebildet werden! Bernd Oberknapp, UB Freiburg

22 ARP-Verwaltung: Autograph
Die Attribute, die an einen Service-Provider weitergegeben werden, werden den Benutzern in Form von Visitenkarten präsentiert. Benutzer können für jeden Service-Provider individuelle Visitenkarten erstellen. Die Bedienung ist sehr intuitiv: Streichen von Attributen schränkt die verfügbaren Dienste entsprechend ein Auswahl eines gewünschten Dienstes fügt automatisch die notwendigen Attribute hinzu Demo Bernd Oberknapp, UB Freiburg