Authentifizierung, Autorisierung und Rechteverwaltung Autorisierung und Zugriffskontrolle in Shibboleth: Attribute Definition, Weitergabe, Verarbeitung

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


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!


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.


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.


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!


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“.


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“


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


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


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.


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


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"/>


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>


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.


ARP-Beispiel: ReDI

<Rule> <Description>ReDI Site-ARP</Description> <Target> <Requester matchFunction="urn:mace:shibboleth:arp:

matchFunction:regexMatch"> ûrn: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"> ûrn:mace:aar:entitlement:[a-z]+:redi:[a-z]+$ </Value> </Attribute>

<Attribute name="urn:mace:dir:attribute-def:eduPersonPrincipalName"> <AnyValue release="permit"/> </Attribute></Rule>


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


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">ûrn:mace:aar:entitlement:.+$ </Value> </AnySite></AttributeRule>


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.


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!


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!


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

Documents

Authentifizierung, Autorisierung und Rechteverwaltung Autorisierung und Zugriffskontrolle in Shibboleth: Attribute Definition, Weitergabe, Verarbeitung