Skip to content
Snippets Groups Projects

Shibboleth-Konfiguration für FDM-Repositorium

  • Clone with SSH
  • Clone with HTTPS
  • Embed
  • Share
    The snippet can be accessed without any authentication.
    Authored by Wörner, Dr. Kai Joachim

    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('')}}"
    Edited
    settings.json 5.90 KiB
    {
        // 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>'
            //      ]
            // }
        }
    }
    0% Loading or .
    You are about to add 0 people to the discussion. Proceed with caution.
    Please register or to comment