Hinweise und Konfigurationsdetails eines Shibboleth IDPs für das GÉANT (formals TERENA) Trusted Certificates Service bzw. genauer für persönliche und "e-science/grid"-Zertifikate – nur solche sind zur Zeit nach SAML-Login bestellbar.
entityID
Der global eindeutige Name des Services lautet: https://www.digicert.com/sso
Attribute
Siehe DigiCert bzw- "GÉANT Trusted Certificate Service (TCS)" auf https://eduid.at/entities/sp. Das Service braucht also zwingend die folgenden Attribute:
- mail (E-Mail-Adresse)
- displayName (voller Name)
- eduPersonPrincipalName (siehe unten)
- schacHomeOrganization (siehe unten)
- eduPersonEntitlement (siehe unten)
eduPersonPrincipalName
Offensichlich ist es keine gute Idee, die Semantik von standardisierten und weltweit eingesetzten Attributen (wie denen des eduPerson-Standards) für eigene Zwecke abweichend festzulegen, wie das hier beim TCS geschieht.
eduPersonEntitlement
Zum Zugriff muß das eduPersonEntitlement Attribut einen der beiden folgenden Werte haben (egal welchen, diese sind mittlerweile equivalent):
urn:mace:terena.org:tcs:personal-user
urn:mace:terena.org:tcs:escience-user
Etwaige früher verwendete "-admin
" Entitlement-Werte sind obsolet und können ggfs. lokal entfernt werden: Die Berechtigung für AdministratorInnen erfolgt direkt (und nur) im DigiCert-System.
N.B.: Diese Entitlements dürfen nur unter bestimmten Bedingungen und nur an berechtigte Personen vergeben werden, wie im TERENA Personal CA Certificate Practice Statement, Abschnitt 3.2.3, beschrieben. ( TODO: Neue Version des CPS!)
schacHomeOrganization
Nachschlagen
Für die schacHomeOrganization
kann man in /opt/shibboleth-idp/conf/attribute-resolver.xml
folgende Attributdefinition eintragen:
<AttributeDefinition id="schacHomeOrganization" xsi:type="Simple" sourceAttributeID="schacHomeOrganization"> <Dependency ref="staticAttributes" /> <AttributeEncoder xsi:type="SAML1String" name="urn:oid:1.3.6.1.4.1.25178.1.2.9" encodeType="false" /> <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.9" friendlyName="schacHomeOrganization" encodeType="false" /> </AttributeDefinition>
Erzeugen
In derselben Datei wird auch die von obiger Attributdefinition referenzierte Abhängigkeit ("staticAttributes" genannt) definiert. Nachdem im einfachsten Fall alle Identitäten eines IDPs zur selben "home organization" (Institution) gehören, kann für alle derselbe Wert generiert werden. Im Beispiel unten geschieht das unter Nutzung der property idp.scope
, welche in conf/idp.properties
definiert wird. Anderenfalls kann dort natürlich eine andre statische Zeichnkette eingetragen werden (z.B. example.ac.at
):
<DataConnector id="staticAttributes" xsi:type="Static"> <Attribute id="schacHomeOrganization"> <Value>%{idp.scope}</Value> </Attribute> </DataConnector>
Attribute weitergeben
Die Weitergabe oben (und a.a.O.) definierter Attribute wird in /opt/shibboleth-idp/conf/attribute-filter.xml
eingerichtet.
Wer bereits den diesbezüglichen Empfehlungen aus diesem Wiki folgt und die Freigaberegel "ACOnet-registered services" übernommen hat, muß hier für TCS nichts weiter tun.
Anderenfalls kann zu der bestehenden Konfiguration etwa folgendes eingetragen werden:
<AttributeFilterPolicy id="TCSportal"> <PolicyRequirementRule xsi:type="Requester" value="https://www.digicert.com/sso" /> <AttributeRule attributeID="eduPersonPrincipalName"> <PermitValueRule xsi:type="ANY" /> </AttributeRule> <AttributeRule attributeID="eduPersonEntitlement"> <PermitValueRule xsi:type="Value" value="urn:mace:terena.org:tcs:personal-user" /> </AttributeRule> <AttributeRule attributeID="schacHomeOrganization"> <PermitValueRule xsi:type="ANY" /> </AttributeRule> <AttributeRule attributeID="displayName"> <PermitValueRule xsi:type="ANY" /> </AttributeRule> <AttributeRule attributeID="mail"> <PermitValueRule xsi:type="ANY" /> </AttributeRule> </afp:AttributeFilterPolicy>