Page History
Hinweise und Konfigurationsdetails eines Shibboleth IDPsIDP 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".
Info |
---|
Siehe ACOnet Zertifikatsservice für allgemeine Informationen. |
entityID
Der global eindeutige Name des SAML Services Providers von Sectigo (dem TCS-Anbieter ab Mitte 2020) lautet: https://www.digicert.com/sso
Attribute
cert-manager.com/shibboleth
Das Service wurde von der InCommon-Federation registriert und wird von dort über eduGAIN weiterpubliziert. D.h. nur jene ACOnet-Teilnehmerinstitutionen, die sowohl an eduID.at als auch an eduGAIN/Interfederation teilnehmen (und die TCS-Zusatzvereinbarung abgeschlossen haben), können sich über ihre eigene Institution bei diesem Service anmelden, sei es für Admin-Zugriffe oder zum Beantragen persönlicher Zertifikate für Endbenutzer*innen.
Attribute
Admin-Zugriff SCM Portal
Für die TCS-Administrator*innen einer Institution ist die Anmeldung am Sectigo Certificate Manager (SCM)-Portal über SAML möglich. Dazu müssen die Attribute:
vom IDP übermittelt werden (und zuvor vom ACOnet-Team im SCM provisioniert worden sein).
Persönliche Zertifikate
Für das Beantragen persönlicher Zertifikate (etwa zum Signieren von E-Mails) braucht das Service Siehe DigiCert bzw. "GÉANT Trusted Certificate Service (TCS)" auf https://eduid.at/entities/sp. Das Service braucht also zwingend die folgenden Attribute:
- mail (institutionelle E-Mail-Adresse)
- displayName (voller Name)
- givenName (Vorname)
- sn (Nachname)
- eduPersonPrincipalName (siehe unten)
- schacHomeOrganization (siehe unten)
- eduPersonEntitlement (siehe unten)
Der Service-URL des SAML Self-Service Portals lautet: https://cert-manager.com/customer/ACOnet/idp/clientgeant – siehe TCS FAQ.
eduPersonPrincipalName
Note | ||
---|---|---|
| ||
Das TCS verengt für seine eigenen Zwecke die Definition von eduPersonPrincipalName (ePPN) und verbietet prinzipiell das Neuvergeben eines bestehenden ePPN an eine andere Person bei Nutzung des TCS Personal Certificate Services. Ein solches Wiederverwenden ist zwar ohnehin fast immer bad practice, wird aber in der für dieses Attribut autoritativen eduPerson-Spezifikation nicht ausgeschlossen. Darüber hinaus wird der ePPN oft aus der lokalen UserID (die zum Login zu Services wie IMAP oder SSH benutzt wird) gebildet, und die Nicht-Wiederverwendung von lokalen UserIDs steht in der Regel nicht zur Debatte, weil lokalen, jeweils unterschiedlichen, institutionellen Entscheidungen und Prozessen unterliegend. |
...
Info | ||
---|---|---|
| ||
Wenn also die Weitergabe bzw. Übernahme einer UserID von einer Person zu einer anderen (auch nach Jahren der "Stilllegung") an einer Institution nicht ausgeschlossen ist, sollte dort die UserID nicht zur Erzeugung des |
Offensichlich ist es keine gute Idee, die Semantik von standardisierten und weltweit eingesetzten Attributen (wie denen des jenen aus eduPerson-Standards) für eigene Zwecke abweichend festzulegen, wie das hier beim TCS geschiehtbei TCS geschehen ist. Aus Gründen der Kompatibiltät mit eingeführten Services wird dieses Attribut aber (bis auf Weiteres) beibehalten.
eduPersonEntitlement
Zum Zugriff Zur Beantragung persönlicher Zertifikate muß das eduPersonEntitlement-Attribut einen der beiden den 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 Administrator*innen erfolgt direkt (und nur) im DigiCert-Systemin SCM.
N.B.: Diese Entitlements dürfen ggfs. nur unter bestimmten Bedingungen und nur an berechtigte Personen vergeben werden, siehe TCS Personal/eSciente/Document Signing CA Certificate Practice Statement, u.a. Abschnitte 3.2.3 und 4.1.1.
schacHomeOrganization
Nachschlagen
Für die schacHomeOrganization
kann man in /opt/shibboleth-idp/conf/attribute-resolver.xml
folgende Attributdefinition eintragen:
Code Block | ||
---|---|---|
| ||
<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. Im Beispiel unten geschieht das unter Nutzung der property idp.scope
, welche in conf/idp.properties
definiert wird. Anderenfalls kann dort stattdessen natürlich eine statische Zeichenkette eingetragen werden (z.B. example.ac.at
):
Code Block | ||
---|---|---|
| ||
<DataConnector id="staticAttributes" xsi:type="Static">
<Attribute id="schacHomeOrganization">
<Value>%{idp.scope}</Value>
</Attribute>
</DataConnector> |
Attribute weitergeben
siehe die jeweils gültigen TCS-Vereinbarungen (TODO).
schacHomeOrganization
Die Dokumentation zum Erzeugen/Nachschlagen von Attributen für den Shibboleth IDP enthält eine fertige Vorlage zum Erzeugen von "schacHomeOrganization".
Attribute weitergeben
Die Weitergabe oben definierter Attribute wird wie üblich
...
in /opt/shibboleth-idp/conf/attribute-filter.xml
eingerichtet
...
Tip |
---|
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. |
...
:
Code Block | ||
---|---|---|
| ||
<AttributeFilterPolicy id="TCSportalTCS"> <PolicyRequirementRule xsi:type="Requester" value="https://www.digicertcert-manager.com/ssoshibboleth" /> <AttributeRule <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" /> <AttributeRule <PermitValueRule xsi:typeattributeID="displayName" permitAny="ANYtrue" /> </AttributeRule> <AttributeRule attributeID="eduPersonEntitlement"givenName" permitAny="true" /> <PermitValueRule xsi:type<AttributeRule attributeID="Valuesn" valuepermitAny="urn:mace:terena.org:tcs:personal-usertrue" /> </AttributeRule> <AttributeRule attributeID="schacHomeOrganizationmail"> <PermitValueRule xsi:type permitAny="ANYtrue" /> </AttributeRule> <AttributeRule attributeID="displayNameschacHomeOrganization"> <PermitValueRule xsi:type permitAny="ANYtrue" /> </AttributeRule> <AttributeRule attributeID="maileduPersonEntitlement"> <PermitValueRule xsi:type="ANY="Value" value="urn:mace:terena.org:tcs:personal-user" /> </AttributeRule> </AttributeFilterPolicy> |
...