Authentifizierung, Autorisierungund Rechteverwaltung
Autorisierung und Zugriffskontrollein Shibboleth: Attribute
Definition, Weitergabe, Verarbeitung
2. Shibboleth-Workshop
Freiburg, 23. März 2006
Bernd Oberknapp, UB Freiburg
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: E-Mailadresse– 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 ihrerRegeln aus und gestatten oder verweigern je nachErgebnis 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: E-Mailadresse).
• 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: http://www.incommonfederation.org/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: [email protected]• 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:adminBenutzer der Universität Stuttgart mit Administratorrechten in ReDI
Bernd Oberknapp, UB Freiburg 10
eduPersonPrincipalName
• Eindeutiger, persistenter Identifier des Benutzers inklusive Domain ("NetID")
• Beispiel: [email protected]• 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"/> </Attribute></Rule>
Bernd Oberknapp, UB Freiburg 17
Attribute filtern im SP: AAP
Die Attribute Acceptance Policy (AAP) desService-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 Type="regexp">^[^@]+$</Value> </AnySite></AttributeRule>
<AttributeRule Name="urn:mace:dir:attribute-def: eduPersonEntitlement"
Header="Shib-EP-Entitlement" Alias="entitlement"> <AnySite> <Value Type="regexp">^urn:mace:aar:entitlement:.+$ </Value> </AnySite></AttributeRule>
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 http://tinyurl.com/dzhfk)• 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