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

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

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

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

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

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

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: member@uni-freiburg.de 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

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

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

eduPersonPrincipalName Eindeutiger, persistenter Identifier des Benutzers inklusive Domain ("NetID") Beispiel: oberknap@uni-freiburg.de 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

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

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

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

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

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

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

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

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"> <Value Type="regexp">^urn:mace:aar:entitlement:.+$ </Value> Bernd Oberknapp, UB Freiburg

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

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

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

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