Startseite > SAML2.0 - Atlassian Shibboleth Service Provider 3
- SAML2.0 - Atlassian Shibboleth Service Provider 3
Installation
Zur allgemeinen Installation befolgen Sie bitte die Service Provider Anweisungen des Shibboleth Consortium.
Am ZIH wird der Betrieb des Atlassian Service Provider unter Debian Linux aufgesetzt. Durch den Support des Shibboleth Consortium bieten die Debian Paketquellen das shibboleth-sp-common Paket an, mit dem die Installation ermöglicht wird.
Die Installation besteht aus dem Service Provider shibd und einen geeigneten Webserver z.B. Apache2 oder Nginx. Nehmen Sie die folgenden Umsetzungen als root vor.
shibd
Der shibd Service Provider ist die Voraussetzung zur Verarbeitung der Identity Provider Daten.
login@server:~$ apt update && apt install shibboleth-sp-utils
Prüfen Sie die erfolgte Installation mit:
login@server:~$ shibd -v
shibboleth 3.4.1
Apache2
Die Installation des Apache2 Webserver erfordert den Webserver selbst sowie das geeignete Shibboleth Modul.
login@server:~$ apt update && apt install apache2 libapache2-mod-shib
Nginx
Für die Installation des Nginx Webservers reicht das Hauptpaket zu.
login@server:~$ apt update && apt install nginx
Konfiguration
Zur Konfiguration des Service Providers sind folgende Punkte zu beachten:
- Festlegung einer weltweiten entityId als URI (siehe entityId)
- Besitz eines SAML Zertifikates für den Datenaustausch (siehe SAML Zertifikat oder SAML Zertifikat erstellen)
- Kenntnisse der SingleSignOn und SingleLogOut Endpunkte (siehe SingleSignOn und SingleLogOut)
- Einbinden des Service Providers in den Webserver
Die Punkte 1-3 werden in der shibd - shibboleth2.xml konfiguriert. Für den Punkt 4 bieten wir ein Beispiel für Apache2 oder Nginx an
shibd - shibboleth2.xml
Die Konfiguration des shibd erfolgt über die /etc/shibboleth/shibboleth2.xml Datei.
<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:3.0:native:sp:config"
clockSkew="180">
<OutOfProcess tranLogFormat="%u|%s|%IDP|%i|%ac|%t|%attr|%n|%b|%E|%S|%SS|%L|%UA|%a" />
<!--
By default, in-memory StorageService, ReplayCache, ArtifactMap, and SessionCache
are used. See example-shibboleth2.xml for samples of explicitly configuring them.
-->
<!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. -->
<ApplicationDefaults entityID="https://sp.example.org/shibboleth"
REMOTE_USER="eppn subject-id pairwise-id persistent-id"
cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">
<!--
Controls session lifetimes, address checks, cookie handling, and the protocol handlers.
Each Application has an effectively unique handlerURL, which defaults to "/Shibboleth.sso"
and should be a relative path, with the SP computing the full value based on the virtual
host. Use of TLS is now assumed because browsers are enforcing it due to SameSite
restrictions. Note that while we default checkAddress to "false", this makes an assertion
stolen in transit easier for attackers to misuse.
-->
<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
checkAddress="false" handlerSSL="true" cookieProps="https"
redirectLimit="exact">
<!--
Configures SSO for a default IdP. To properly allow for >1 IdP, remove
entityID property and adjust discoveryURL to point to discovery service.
You can also override entityID on /Login query string, or in RequestMap/htaccess.
-->
<SSO entityID="https://idp.example.org/idp/shibboleth"
discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
SAML2
</SSO>
<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>
<!-- Administrative logout. -->
<LogoutInitiator type="Admin" Location="/Logout/Admin" acl="127.0.0.1 ::1" />
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
<!-- Status reporting service. -->
<Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
<!-- Session diagnostic service. -->
<Handler type="Session" Location="/Session" showAttributeValues="false"/>
<!-- JSON feed of discovery information. -->
<Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
</Sessions>
<!--
Allows overriding of error template information/filenames. You can
also add your own attributes with values that can be plugged into the
templates, e.g., helpLocation below.
-->
<Errors supportContact="root@localhost"
helpLocation="/about.html"
styleSheet="/shibboleth-sp/main.css"/>
<!-- Example of locally maintained metadata. -->
<!--
<MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>
-->
<!-- Example of remotely supplied batch of signed metadata. -->
<!--
<MetadataProvider type="XML" validate="true"
url="http://federation.org/federation-metadata.xml"
backingFilePath="federation-metadata.xml" maxRefreshDelay="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="fedsigner.pem" verifyBackup="false"/>
<DiscoveryFilter type="Exclude" matcher="EntityAttributes" trimTags="true"
attributeName="http://macedir.org/entity-category"
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
attributeValue="http://refeds.org/category/hide-from-discovery" />
</MetadataProvider>
-->
<!-- Example of remotely supplied "on-demand" signed metadata. -->
<!--
<MetadataProvider type="MDQ" validate="true" cacheDirectory="mdq"
baseUrl="http://mdq.federation.org" ignoreTransport="true">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="mdqsigner.pem" />
</MetadataProvider>
-->
<!-- Map to extract attributes from SAML assertions. -->
<AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
<!-- Default filtering policy for recognized attributes, lets other data pass. -->
<AttributeFilter type="XML" validate="true" path="attribute-policy.xml"/>
<!-- Simple file-based resolvers for separate signing/encryption keys. -->
<CredentialResolver type="File" use="signing"
key="sp-key.pem" certificate="sp-cert.pem"/>
<CredentialResolver type="File" use="encryption"
key="sp-key.pem" certificate="sp-cert.pem"/>
</ApplicationDefaults>
<!-- Policies that determine how to process and authenticate runtime messages. -->
<SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
<!-- Low-level configuration about protocols and bindings available for use. -->
<ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
</SPConfig>
Passen Sie diese Datei entsprechend der nachfolgenden Punkte an. Im Anschluss ist es nötig den shibd erneut zu starten mit:
login@server:~$ systemctl restart shibd.service
Eine Prüfung der Konfiguration können Sie mit folgendem Befehl vornehmen:
login@server:~$ shibd -t
Setzen der entityId
Setzen Sie unter https://sp.example.org/shibboleth Ihre entityId, die zukünftig für Ihren Service Provider verwendet werden soll. Beachten Sie bitte auch die Hinweise zur entityId.
<ApplicationDefaults entityID="https://sp.example.org/shibboleth"
REMOTE_USER="eppn subject-id pairwise-id persistent-id"
cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1">
Sicherheitseinstellung für Shibboleth Session
Passen Sie die Shibboleth Session Angaben an Ihre Anwendung an. So erhöhen Sie die Sicherheit der Nutzer.
<Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
checkAddress="false" handlerSSL="true" cookieProps="https"
redirectLimit="exact">
Folgende Optionen wären denkbar:
| Name | Wert | Beschreibung |
|---|---|---|
| consistentAddress | [true false] | IP-Adresse des Nutzers darf sich während der Session nicht ändern (Verhinderung von Man-In-The-Middle Attacken) |
| cookieProps | [http https] | Cookies sind nur via HTTPS zulässig |
| lifetime | Integer | Gültigkeit der Session in Sekunden |
| redirectLimit | exact | Redirect nur zum aufgerufenen Protokoll/Host/Port (Missbrauch des SPs für Phishing-Angriffe verhindern) |
| handlerSSL | true | Übertragung erfolgt per SSL |
| checkAddress | [true false] | Prüfe ob IP-Adresse identisch mit der SAML-Assertion des IdP ist |
Festlegen der Identity Provider
Legen Sie den IdP mit https://idp.example.org/idp/shibboleth fest. Entfernen Sie die entityId="...", so wird die Discovery-Funktion
wirksam. Diese erfolgt über den Endpunkt Ihres Service Providers. Setzen Sie für ds.example.org Ihre Domain ein.
| Test | https://idp3-test.tu-dresden.de/idp/shibboleth |
| Produktion | https://idp.tu-dresden.de/idp/shibboleth |
<SSO entityID="https://idp.example.org/idp/shibboleth"
discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
SAML2
</SSO>
Single Logout (SLO)
<Logout>SAML2 Local</Logout>
Die Reihenfolge gibt an, welches Verfahren vom SP beim Logout initiiert wird.
| SAML2 | beendet die lokale Session am SP und leitet die Nutzenden zum weiteren Logout-Vorgang an den IdP weiter |
| Local | beendet "nur" die lokale Session am SP |
Hinweis: Bei Local-Logout wird empfohlen dem Nutzer einen Hinweis zu geben, dass er womöglich bei weiteren Diensten eingeloggt sein könnte!
IdP Metadaten einbinden
Zum Aufbau der Vertrauensstellung ist es nötig die Metadaten des/der IdPs zu kennen. Die DFN-AAI hält unter https://doku.tid.dfn.de/de:metadata die föderierten IdPs bereit.
| Test-IdPs | http://www.aai.dfn.de/metadata/dfn-aai-test-metadata.xml |
| Produktive-IdPs | http://www.aai.dfn.de/metadata/dfn-aai-idp-metadata.xml |
Der manuelle Bezug zum Download der IdP Metadaten der Technischen Universität Dresden ist hier möglich:
| Test | https://idp3-test.tu-dresden.de/idp/shibboleth |
| Produktion | https://idp.tu-dresden.de/idp/shibboleth |
Folgende Anpassungen wären für produktive IdPs vorstellbar. Diese bezieht die föderierten IdPs der DFN-AAI. Diese Angaben sind signiert mit dem Zertifikat https://www.aai.dfn.de/metadata/dfn-aai.pem. Von allen föderierten IdPs wird ein Filter auf den IdP der Technischen Universität Dresden und der Hochschule für Technik und Wirtschaft Dresden verwendet.
<!-- Example of locally maintained metadata. -->
<!--
<MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>
-->
<MetadataProvider type="XML" validate="true"
url="http://www.aai.dfn.de/metadata/dfn-aai-idp-metadata.xml"
backingFilePath="dfn-aai-metadata.xml" maxRefreshDelay="7200">
<MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
<MetadataFilter type="Signature" certificate="https://www.aai.dfn.de/metadata/dfn-aai.pem" verifyBackup="false"/>
<MetadataFilter type="Include">
<Include>https://idp.tu-dresden.de/idp/shibboleth</Include>
<Include>https://idp.htw-dresden.de/idp/shibboleth</Include>
</MetadataFilter>
</MetadataProvider>
SAML Zertifikat festlegen
Die SAML Kommunikation mit dem IdP der Technischen Universität Dresden findet ausschließlich signiert (signing) und verschlüsselt (encryption) statt. Es wird empfohlen für beide Varianten dasselbe SAML Zertifikat zu verwenden. Mit sp-cert.pem und sp-key.pem legen Sie fest, wo der shibd die Zertifikate findet. Wichtig: Der shibd benötigt Leseberechtigungen auf diese Dateien!
<!-- Simple file-based resolvers for separate signing/encryption keys. -->
<CredentialResolver type="File" use="signing"
key="sp-key.pem" certificate="sp-cert.pem"/>
<CredentialResolver type="File" use="encryption"
key="sp-key.pem" certificate="sp-cert.pem"/>
Hinweis: Das Debian Paket shibboleth-sp-utils besitzt ein Tool shib-keygen mit dem ein eigenes SAML Zertifikat erstellt werden kann. Möchten Sie die Konfiguration sp-cert.pem und sp-key.pem behalten, so können Sie Ihr SAML Zertifikat für ein Jahr mit folgendem Aufruf generieren:
login@server:~$ shib-keygen -e https://mein-sp.de/shibboleth -y 1 -h https://mein-sp.de -f
Zusätzliche Informationen in den Metadaten
Zur Ergänzung weiterer Informationen in den Metadaten kann der <Handler>-Tag vom Typ MetadataGenerator gesetzt werden. Erweitern Sie dazu das Tag SPConfig mit den Attributen xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" und xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata".
<SPConfig xmlns="urn:mace:shibboleth:3.0:native:sp:config"
xmlns:conf="urn:mace:shibboleth:3.0:native:sp:config"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
clockSkew="180">
<ApplicationDefaults ...>
<Sessions ...>
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false">
<mdui:UIInfo>
<mdui:DisplayName xml:lang="de">Server ZIH</mdui:DisplayName>
<mdui:DisplayName xml:lang="en">Server ZIH</mdui:DisplayName>
<mdui:Description xml:lang="de">Portal für Angestellte ...</mdui:Description>
<mdui:Description xml:lang="en">Portal for employees ...</mdui:Description>
<mdui:Logo height="15" width="16">https://mein-sp.de/images/pic.png</mdui:Logo>
<mdui:Logo height="140" width="146">https://mein-sp.de/images/big_pic.png</mdui:Logo>
<mdui:InformationURL xml:lang="de">https://mein-sp.de/</mdui:InformationURL>
<mdui:InformationURL xml:lang="en">https://mein-sp.de/</mdui:InformationURL>
<mdui:PrivacyStatementURL xml:lang="de">https://mein-sp.de/impressum</mdui:PrivacyStatementURL>
<mdui:PrivacyStatementURL xml:lang="en">https://mein-sp.de/impressum</mdui:PrivacyStatementURL>
</mdui:UIInfo>
<md:AttributeConsumingService index="1">
<md:ServiceName xml:lang="de">Server ZIH</md:ServiceName>
<md:ServiceName xml:lang="en">Server ZIH</md:ServiceName>
<md:ServiceDescription xml:lang="de">Portal für Angestellte ...</md:ServiceDescription>
<md:ServiceDescription xml:lang="en">Portal for employees ...</md:ServiceDescription>
<md:RequestedAttribute FriendlyName="eduPersonScopedAffiliation" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<md:RequestedAttribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="false"/>
</md:AttributeConsumingService>
<md:Organization>
<md:OrganizationName xml:lang="de">TU Dresden</md:OrganizationName>
<md:OrganizationName xml:lang="en">TU Dresden</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="de">Technische Universität Dresden</md:OrganizationDisplayName>
<md:OrganizationDisplayName xml:lang="en">Technische Universität Dresden</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="de">https://www.tu-dresden.de</md:OrganizationURL>
<md:OrganizationURL xml:lang="en">https://www.tu-dresden.de</md:OrganizationURL>
</md:Organization>
<md:ContactPerson contactType="support">
<md:GivenName>Service</md:GivenName>
<md:SurName>Desk</md:SurName>
<md:EmailAddress>servicedesk@tu-dresden.de</md:EmailAddress>
</md:ContactPerson>
<md:ContactPerson contactType="technical">
<md:GivenName>Technischer</md:GivenName>
<md:SurName>Ansprechpartner</md:SurName>
<md:EmailAddress>techniker@tu-dresden.de</md:EmailAddress>
</md:ContactPerson>
<md:ContactPerson contactType="administrative">
<md:GivenName>Administrativer</md:GivenName>
<md:SurName>Ansprechpartner</md:SurName>
<md:EmailAddress>admin@tu-dresden.de</md:EmailAddress>
</md:ContactPerson>
</Handler>
Metadaten generieren
Der shibd bietet einen Metadatengenerator an. Dieser ist per Standard unter dem Endpunkt /Metadata abrufbar. Je nachdem wie Sie Ihren Webserver konfigurieren, ist es möglich Ihre Metadaten zum Download anzubieten z.B. https://mein-sp.de/Shibboleth.sso/Metadata.
<!-- Extension service that generates "approximate" metadata based on SP configuration. -->
<Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
Eine Alternative bietet das Tool shib-metagen an, mit dem die Metadaten generiert werden.
login@server:~$ shib-metagen -2 -L -c /etc/shibboleth/sp-cert.pem -h https://mein-sp.de -e https://mein-sp.de/shibboleth -a Max/Mustermann/max.mustermann@mein-sp.de
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://mein-sp.de/shibboleth">
<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIIEJDCCAoygAwIBAgIUMlFg3PvMj7p/gyEjfgq9VNSpLkIwDQYJKoZIhvcNAQEL
BQAwHzEdMBsGA1UEAxMUaHR0cHM6Ly9tZWluLXRlc3QuZGUwHhcNMjUwMzI4MTU0
NDE5WhcNMjYwMzI4MTU0NDE5WjAfMR0wGwYDVQQDExRodHRwczovL21laW4tdGVz
dC5kZTCCAaIwDQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANGA+7YSxE1u2N/p
2vK/PNg26ORRTMtpi46KnE2L0EM7jNhz81p4zXY/72hjuphKljHjJR2xPyL5Uxg2
XuD/28MhiUA+rfM9eoIre69qBEXm9AWJPaL6L833/EhcYkjUBgK5q9xpH7uWxdu2
v7n1zwdjs86DZ87LB3mslk5VUFvbGD9g03QM5f87mlLPg4pXg1RGbpFd1qxwZDVN
NTpL1uKTn04raWQj7i/TBOslbXhFONYCFtENkdd9r0Kvv89o7fDOrk7ty6ARHqkd
f4uMoXeMHrRNvMzivSvHZRjAitfdo2yU82xHrruQZaqp8SnTUdtZi8Cg+fLwjTKt
DIye+Z86kNeyBOY93sCnthFQmzykTU0jR9lvFFxqXgcRDnmi8g0E8bHC5TXueJ+m
JjINZGcDFEeIRDr2z+AoDxx5vo0Z3MNUp2A3CqpRfdsZNswISK5eHCWPXHkBKPNG
mI+gh2a4UWdp7g3t1w7v5vGFJRxhXq62FGcv1Tb+Sj+r/KkdwQIDAQABo1gwVjA1
BgNVHREELjAsghRodHRwczovL21laW4tdGVzdC5kZYYUaHR0cHM6Ly9tZWluLXRl
c3QuZGUwHQYDVR0OBBYEFEEdnGViCUSXdORVTSg1cZt2yYAAMA0GCSqGSIb3DQEB
CwUAA4IBgQAtEFfyi3W0yT2X/F8invf9J20P1baQ4nEXBZ+1GWzKk3QLdrsVdVfJ
hAoRN2AebidtrjT4XKZDNVV3PQoroonvNdWW3BmP8cp2rIdto7RYwGGyqAgsY8o9
OoHP4NBC3Ri3w2qWPxhYrAeqOwB9Ja3ThJZTR7bXexvmxbyRGoEDYk7uwZ5FIYrW
hy4ui8TzS/t5gJCZ30cWiq3rJ337QZbaCwdH0wA9AaxZMxLuDcEbvZz5SpBWijs3
XGWDi0TB4TqVZ12HSgRObZPCDTzCnY+2bz2lXLDU4j5pcutIHeCr9KrWnoHSvUTP
vrYCVMqAyd1D0HaBLMXi4tnRwRFunoGGIrRhDmQ29p8Egtf6x+wkptBH5VdSW36N
VVUUY8/g0G/8ftjAAcuPh2Z7x/CUY36pre2LE1HryepOup7CSGSCl7oqDrLzReAp
K3DjLmlKUhI49TkKC6V81ZjCgbJJIXVwDRnnFKjDaTqFYClIN3HbV2Sn3J0I8aSI
nIcwxEMBD8g=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://https://mein-sp.de/Shibboleth.sso/SLO/SOAP"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://https://mein-sp.de/Shibboleth.sso/SLO/Redirect"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://mein-sp.de/Shibboleth.sso/SLO/POST"/>
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://https://mein-sp.de/Shibboleth.sso/SLO/Artifact"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://https://mein-sp.de/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://https://mein-sp.de/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://https://mein-sp.de/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://https://mein-sp.de/Shibboleth.sso/SAML2/ECP" index="4"/>
</md:SPSSODescriptor>
<md:ContactPerson contactType="administrative">
<md:GivenName>Max</md:GivenName>
<md:SurName>Mustermann</md:SurName>
<md:EmailAddress>max.mustermann@mein-sp.de</md:EmailAddress>
</md:ContactPerson>
</md:EntityDescriptor>
Apache2
Mit folgenden Schritten nehmen Sie eine Anpassung Ihrer Apache2 Konfiguration vor und schützen den Endpunkt /secure mit einer Shibboleth Authentifizierung.
Im Anschluss den Apache2 Webserver neustarten.
# Konfiguration auf Korrektheit prüfen
login@server:~$ httpd -t
Syntax OK
# Apache neu starten
login@server:~$ systemctl restart apache2.service
shibd Modul einbinden
Mit folgendem Befehl laden Sie das shibd Modul in den Apache2, sofern dies während der Installation nicht schon vorgenommen wurde.
login@server:~$ a2enmod shib
Module shib already enabled
Folgende Konfiguration sollte nun verfügbar sein:
login@server:~$ cat /etc/apache2/mods-enabled/shib.load
LoadModule mod_shib /usr/lib/apache2/modules/mod_shib.so
Anpassen der vHosts
Konfigurieren Sie Ihre vHosts unter /etc/apache2/sites-available/. In unserem Beispiel wird die Datei /etc/apache2/sites-available/000-default.conf verwendet.
<VirtualHost *:443>
# disable TRACK/TRACE:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/my_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/my_key.pem
SSLCertificateChainFile /etc/apache2/ssl/my_ca.pem
# best practice(apache/modern) from https://ssl-config.mozilla.org/
# enable HTTP/2, if available
Protocols h2 http/1.1
# HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
Header always set Strict-Transport-Security "max-age=63072000"
# modern configuration
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
# Needed for shibd endpoints
<Location /Shibboleth.sso>
AuthType None
Require all granted
</Location>
DocmentRoot /var/www/html
Alias /start /var/www/html
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession true
require shib-session
</Location>
</VirtualHost>
Empfohlene SSL Konfiguration
Beispielempfehlungen für den sicheren Apache2 Serverbetrieb. Empfehlungen von https://ssl-config.mozilla.org/.
<VirtualHost *:443>
# disable TRACK/TRACE:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/my_cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/my_key.pem
SSLCertificateChainFile /etc/apache2/ssl/my_ca.pem
# best practice(apache/modern) from https://ssl-config.mozilla.org/
# enable HTTP/2, if available
Protocols h2 http/1.1
# modern configuration
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
shibd Endpoints
Folgende Location gewährt den Zugriff auf die shibd Endpoints.
# Needed for shibd endpoints
<Location /Shibboleth.sso>
AuthType None
Require all granted
</Location>
Ressourcen/Anwendung schützen
Folgende Location schützt den Zugriff mit einer Shibboleth Authentifizierung ab.
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession true
require valid-user
</Location>
Nginx
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name mein-sp.de;
ssl_certificate /path/to/your/certificate.crt;
ssl_certificate_key /path/to/your/private.key;
# modern configuration
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
# replace with the IP address of your resolver;
# async 'resolver' is important for proper operation of OCSP stapling
resolver 127.0.0.1;
location /secure {
# Shibboleth-Authentifizierung erzwingen
auth_request /Shibboleth.sso/auth;
auth_request_set $user $upstream_http_remote_user;
# Weiterleitung an Ihre Anwendung
proxy_pass http://127.0.0.1:your_app_port;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Remote-User $user; #Übergabe des Benutzers an die Anwendung.
# Weitere Header, die von Shibboleth bereitgestellt werden können
# proxy_set_header eppn $upstream_http_eppn;
# proxy_set_header affiliation $upstream_http_affiliation;
}
location /Shibboleth.sso {
# Shibboleth-Endpunkte weiterleiten
proxy_pass http://unix:/run/shibboleth/shibd.sock;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Empfohlene SSL Konfiguration
Beispielempfehlungen für den sicheren Nginx Serverbetrieb. Empfehlungen von https://ssl-config.mozilla.org/.
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name mein-sp.de;
ssl_certificate /path/to/your/certificate.crt;
ssl_certificate_key /path/to/your/private.key;
# modern configuration
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
# replace with the IP address of your resolver;
# async 'resolver' is important for proper operation of OCSP stapling
resolver 127.0.0.1;
Ressourcen/Anwendung schützen
location /secure {
# Shibboleth-Authentifizierung erzwingen
auth_request /Shibboleth.sso/auth;
auth_request_set $user $upstream_http_remote_user;
# Weiterleitung an Ihre Anwendung
proxy_pass http://127.0.0.1:your_app_port;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Remote-User $user; #Übergabe des Benutzers an die Anwendung.
# Weitere Header, die von Shibboleth bereitgestellt werden können
# proxy_set_header eppn $upstream_http_eppn;
# proxy_set_header affiliation $upstream_http_affiliation;
}
shibd Endpoints
location /Shibboleth.sso {
# Shibboleth-Endpunkte weiterleiten
proxy_pass http://unix:/run/shibboleth/shibd.sock;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Debugging
shibd Logging
Die Shibboleth Daten werden verschlüsselt übertragen. Ein SAML Tracer Plugin im Webbrowser ist nicht wirklich nützlich. Der shibd entschlüsselt die SAML Daten nach dem Empfang. Um diese Lesen zu können, können Sie in der Datei /etc/shibboleth/shibd.logger den Debug Modus aktivieren.
# set overall behavior
log4j.rootCategory=DEBUG, shibd_log, warn_log
Starten Sie den shibd neu und Sie haben die Möglichkeit die SAML Assertion unverschlüsselt in /var/log/shibboleth/shibd.log zu lesen. Vergessen Sie nicht den Debug Modus zurückzusetzen. Andernfalls loggen Sie sensible Nutzerdaten.
Auch ein Blick in das /var/log/shibboleth/transaction.log lohnt sich, um zu erfahren welche Daten in welcher Session verfügbar waren.
Mapping von Attributen
Der IdP liefert die Attribute mit den entsprechenden OIDs aus. Damit der shibd Service Provider diese OIDs verarbeiten kann, müssen diese in der Datei /etc/shibboleth/attribute-map.xml verfügbar und gemappt sein.
Achten Sie darauf, dass die entsprechenden OIDs in dieser Datei vorhanden ist und verwendet werden. Weiterhin können Sie dort den Namen festlegen mit der die Werte vom IdP in Ihre Webserver Session eingehen.
Shibboleth IdP Login testen
Sie möchten den Login über den IdP testen, unabhängig davon, ob Sie eine geschützte Ressource besitzen? Dafür können Sie Ihren SP mit https://mein-sp.de/Shibboleth.sso/Login ansprechen, sodass dieser ein Login am IdP initiiert.
Shibboleth IdP Logout testen
Sie möchten den Logout über den IdP testen? Dafür können Sie Ihren SP mit https://mein-sp.de/Shibboleth.sso/Logout ansprechen. Im Anschluss wird die Shibboleth Session des Nutzers gelöscht.
Shibboleth SP Session prüfen
Haben Sie sich erfolgreich über den IdP authentifiziert und die Shibboleth Session zu Ihrem SP wurde hergestellt, so können Sie mit dem Aufruf https://mein-sp.de/Shibboleth.sso/Session die Session prüfen.
Shibboleth SP Status prüfen
Der SP liefert eine Statusseite über https://mein-sp/Shibboleth.sso/Status. Bitte beachten Sie, dass die /etc/shibboleth/shibboleth2.xml diesen Endpunkt per Standard nur für 127.0.0.1 zugänglich macht.
Auslesen von Shibboleth Attributen
Unterstützt Ihr Webserver PHP, so können Sie folgende Datei als index.php in Ihr Webserver Root Verzeichnis legen:
<?php
phpinfo();
?>
Die IdP Daten werden auf Variablen wie affiliation, schacUserStatus oder entitlement gemappt. Hierbei handelt es sich nur um ein Beispiel. Ihre IdP Daten definieren Sie bei der Beantragung.
Sonstiges
shibd Zertifikatsrollover
SAML Zertifikate besitzen eine entsprechende Gültigkeit, sodass diese in regelmäßigen Abständen aktualisiert werden müssen. Alle IdPs benötigen das neue SAML Zertifikat, um weiterhin mit dem SP verschlüsselt Daten austauschen zu können. Ein Zertifikatsrollover mit dem shibd sollte zeitlich gut geplant sein (siehe: https://doku.tid.dfn.de/de:certificates#zertifikatstausch_am_sp). Eine Alternative zum Zertifikatsrollover wäre: SAML Zertifikatstausch ohne Rollover.
1. shibboleth2.xml vorbereiten
Passen Sie Ihre /etc/shibboleth/shibboleth2.xml Konfiguration wie folgt an. Der SP ist damit in der Lage die IdP-Daten mit altem bzw. neuem SAML Zertifikat zu entschlüsseln. Achten Sie dabei darauf, dass der shibd Leseberechtigungen auf die Zertifikatsdateien besitzt!
<CredentialResolver type="Chaining">
<!-- noch aktives altes Zertifikat -->
<CredentialResolver type="File"
key="sp-cert.pem"
certificate="sp-key.pem"/>
<!-- zusätzliches neues Zertifikat -->
<CredentialResolver type="File"
key="sp-cert-new.pem"
certificate="sp-key-new.pem"/>
</CredentialResolver>
Der shibd muss daraufhin neugestartet werden (siehe shibd - shibboleth2.xml).
2. Neues SAML Zertifikat veröffentlichen
Damit die IdPs das neue SP SAML Zertifikat kennen, muss das sp-cert-new.pem über die Metadaten bekannt gemacht werden. Dafür genügt das Hinzufügen im DFN-AAI Metadatenverwaltung (MDV) an der Entity des SPs und eine Wartezeit von 24h. Ohne DFN-AAI Metdatenverwaltung müssen die entsprechenden IdP Betreiber kontaktiert werden, um die Metadaten des SPs zu aktualisieren.
3. shibboleth2.xml SAML Zertifikate tauschen
Tauschen Sie die Reihenfolge der SAML Zertifikate in /etc/shibboleth/shibboleth2.xml, sodass der SP zukünftig das neue SAML Zertifikat zur Kommunikation mit den IdPs verwendet. Voraussetzung ist der Schritt 2, sodass alle IdPs das neue SP SAML Zertifikat kennen und diesem vertrauen.
<CredentialResolver type="Chaining">
<!-- neues Zertifikat -->
<CredentialResolver type="File"
key="sp-cert-new.pem"
certificate="sp-key-new.pem"/>
<!-- noch aktives altes Zertifikat -->
<CredentialResolver type="File"
key="sp-cert.pem"
certificate="sp-key.pem"/>
</CredentialResolver>
Der shibd muss daraufhin neugestartet werden (siehe shibd - shibboleth2.xml).
4. Altes SAML Zertifikat entfernen
Entfernen Sie das alte Zertifikat sp-cert.pem aus der DFN-AAI Metadatenverwaltung (MDV) an der Entity des SP. Mit einer Wartezeit von 24h sollten die IdPs nur noch das neue SAML Zertifikat für den Betrieb verwenden.
5. shibboleth2.xml altes SAML Zertifikat entfernen
Nachdem sichergestellt sein sollte, dass alle IdPs ausschließlich das neue SAML Zertifikat für den Betrieb verwenden, kann das alte SAML Zertifikat aus der /etc/shibboleth/shibboleth2.xml entfernt werden.
<CredentialResolver type="Chaining">
<!-- neues Zertifikat -->
<CredentialResolver type="File"
key="sp-cert-new.pem"
certificate="sp-key-new.pem"/>
<!-- noch aktives altes Zertifikat -->
<!--
<CredentialResolver type="File"
key="sp-cert.pem"
certificate="sp-key.pem"/>
-->
</CredentialResolver>
Der shibd muss daraufhin neugestartet werden (siehe shibd - shibboleth2.xml).