Shibboleth-Konfiguration für FDM-Repositorium
Installation
Im Wesentlichen muss das Modul nur installiert und konfiguriert werden, weitere Anpassungen sollten eigentlich nötig sein. Für die Installation folgenden Schritten folgen:
https://tobiasfrust.github.io/shibboleth-authenticator/installation.html
Konfiguration
Um das Modul zu aktivieren muss die Konfigurationsvariable
SHIBBOLETH_REMOTE_APPS
in die Konfiguration mit aufgenommen werden, die
schematisch wie folgt aussehen könnte:
SHIBBOLETH_REMOTE_APPS = {
'test': {
'saml_path': '<path_to_settings_folder>',
'mappings': {
'email': 'email_key',
'user_unique_id': 'uuid_key',
'full_name': 'name_key'
}
}
}
Unter mappings
muss festgelegt werden, wie die Parameter, die vom IDP kommen
auf die benötigten Parameter in der jeweiligen Anwendung umgelegt werden.
Außerdem muss der saml_path
angegeben werden, der den Pfad zu dem Ordner
angibt, der die Konfiguration für python3-saml enthält. Für die Konfiguration
ist es vermutlich nötig, sich mit dem Administrator des IDP zu unterhalten.
(https://github.com/onelogin/python3-saml#settings)
Der Ordner ist dann wie folgt strukturiert:
- settings/
- settings.json
- advanced_settings.json
- certs/
- sp.crt
- sp.key
Wenn alles richtig eingerichtet ist, dann ist unter der folgenden URL eine XML Datei aufrufbar:
https://<domain_or_ip>/shibboleth/metadata/test (der letzte Teil entspricht dem Key in der Konfigurationsvariable)
Die Url für den Login habe ich im Template dann wie folgt erzeugt:
"{{[url_for('shibboleth_authenticator.login', remote_app='test'), '?next=', request.args.get('next') | urlencode] | join('')}}"
{
// If strict is True, then the Python Toolkit will reject unsigned
// or unencrypted messages if it expects them to be signed or encrypted.
// Also it will reject the messages if the SAML standard is not strictly
// followed. Destination, NameId, Conditions ... are validated too.
"strict": true,
// Enable debug mode (outputs errors).
"debug": true,
// Service Provider Data that we are deploying.
"sp": {
// Identifier of the SP entity (must be a URI)
"entityId": "https://<sp_domain>/metadata/",
// Specifies info about where and how the <AuthnResponse> message MUST be
// returned to the requester, in this case our SP.
"assertionConsumerService": {
// URL Location where the <Response> from the IdP will be returned
"url": "https://<sp_domain>/?acs",
// SAML protocol binding to be used when returning the <Response>
// message. OneLogin Toolkit supports this endpoint for the
// HTTP-POST binding only.
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
},
// Specifies info about where and how the <Logout Response> message MUST be
// returned to the requester, in this case our SP.
"singleLogoutService": {
// URL Location where the <Response> from the IdP will be returned
"url": "https://<sp_domain>/?sls",
// SAML protocol binding to be used when returning the <Response>
// message. OneLogin Toolkit supports the HTTP-Redirect binding
// only for this endpoint.
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
},
// If you need to specify requested attributes, set a
// attributeConsumingService. nameFormat, attributeValue and
// friendlyName can be ommited
"attributeConsumingService": {
"serviceName": "SP test",
"serviceDescription": "Test Service",
"requestedAttributes": [
{
"name": "",
"isRequired": false,
"nameFormat": "",
"friendlyName": "",
"attributeValue": []
}
]
},
// Specifies the constraints on the name identifier to be used to
// represent the requested subject.
// Take a look on src/onelogin/saml2/constants.py to see the NameIdFormat that are supported.
"NameIDFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
// Usually x509cert and privateKey of the SP are provided by files placed at
// the certs folder. But we can also provide them with the following parameters
"x509cert": "",
"privateKey": ""
/*
* Key rollover
* If you plan to update the SP x509cert and privateKey
* you can define here the new x509cert and it will be
* published on the SP metadata so Identity Providers can
* read them and get ready for rollover.
*/
// 'x509certNew': '',
},
// Identity Provider Data that we want connected with our SP.
"idp": {
// Identifier of the IdP entity (must be a URI)
"entityId": "https://app.onelogin.com/saml/metadata/<onelogin_connector_id>",
// SSO endpoint info of the IdP. (Authentication Request protocol)
"singleSignOnService": {
// URL Target of the IdP where the Authentication Request Message
// will be sent.
"url": "https://app.onelogin.com/trust/saml2/http-post/sso/<onelogin_connector_id>",
// SAML protocol binding to be used when returning the <Response>
// message. OneLogin Toolkit supports the HTTP-Redirect binding
// only for this endpoint.
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
},
// SLO endpoint info of the IdP.
"singleLogoutService": {
// URL Location of the IdP where SLO Request will be sent.
"url": "https://app.onelogin.com/trust/saml2/http-redirect/slo/<onelogin_connector_id>",
// SAML protocol binding to be used when returning the <Response>
// message. OneLogin Toolkit supports the HTTP-Redirect binding
// only for this endpoint.
"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
},
// Public x509 certificate of the IdP
"x509cert": "<onelogin_connector_cert>"
/*
* Instead of using the whole x509cert you can use a fingerprint in
* order to validate a SAMLResponse.
* (openssl x509 -noout -fingerprint -in "idp.crt" to generate it,
* or add for example the -sha256 , -sha384 or -sha512 parameter)
*
* If a fingerprint is provided, then the certFingerprintAlgorithm is required in order to
* let the toolkit know which algorithm was used.
Possible values: sha1, sha256, sha384 or sha512
* 'sha1' is the default value.
*
* Notice that if you want to validate any SAML Message sent by the HTTP-Redirect binding, you
* will need to provide the whole x509cert.
*/
// "certFingerprint": "",
// "certFingerprintAlgorithm": "sha1",
/* In some scenarios the IdP uses different certificates for
* signing/encryption, or is under key rollover phase and
* more than one certificate is published on IdP metadata.
* In order to handle that the toolkit offers that parameter.
* (when used, 'x509cert' and 'certFingerprint' values are
* ignored).
*/
// 'x509certMulti': {
// 'signing': [
// '<cert1-string>'
// ],
// 'encryption': [
// '<cert2-string>'
// ]
// }
}
}