Specify policy configurations based on the registration authority

[johanlundberg]

Allow the use of registration authorities in policy configuration.
This should work in the same way as for the policies written for specific SPs.

Example configuration

"idp": {
    "policy": {
        "a-service-entity-id": {
            ...
        }
        "a-registration-authority-name": {
            "attribute_restrictions": {
                "givenName": None,
            },
        },
        "default": {
            ...
        }
    }
}

References

• SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0
  https://docs.oasis-open.org/security/saml/Post2.0/saml-metadata-rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.html

All Submissions:

• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you added an explanation of what problem you are trying to solve with this PR?
• Have you added information on what your changes do and why you chose this as your solution?
• Have you written new tests for your changes?
• Does your submission pass tests?
• This project follows PEP8 style guide. Have you run your code against the 'flake8' linter?

[c00kiemon5ter]

Policy needs a metadata store to look up attributes (entity-categories, registration-authority, etc).

Previously filter, restrict, and get_entity_categories requested the metadata store (aka mds, mdstore) as a param. Now, the one that has been supplied during initialization is used.

[c00kiemon5ter]

There are many changes, but this is the core of it.

To make this possible, the config module changed to build a Policy object with the metadata store. The metadata store must have been loaded beforehand.

Once the Policy object got a metadata-store object, the interfaces were refactored to remove the explicit param. The tests where then adjusted.

[c00kiemon5ter]

Use the sp_restrictions, else the ra_restrictions, else the default_restrictions - there is no more a default for the registration authorities; SPs and RAs are mixed on the same list.

[c00kiemon5ter]

this should be further refactored

[c00kiemon5ter]

I think this is fine now and we should go ahead and merge 👍

@johanlundberg do have a look, and if you can test it, and let me know.

[c00kiemon5ter]

There are some breaking changes in this PR

• saml2.config.Config.load does not accept the metadata_construction param
• saml2.config.Config.load_file does not accept the metadata_construction param
• saml2.assertion.Policy.restrict does not accept the metadata param
• saml2.assertion.Policy.filter does not accept the mdstore param

[johanlundberg]

@c00kiemon5ter I approve :) If I am able I will try it in our staging environment but don't let that stop you from merging this to master if I am slow.

[johanlundberg]

This feature is now running in our staging environment and fixes the attribute release problem we had when trying to be compliant with https://release-check.swamid.se/.

[c00kiemon5ter]

There are some breaking changes in this PR

• saml2.config.Config.load does not accept the metadata_construction param
• saml2.config.Config.load_file does not accept the metadata_construction param
• saml2.assertion.Policy.restrict does not accept the metadata param
• saml2.assertion.Policy.filter does not accept the mdstore param

Instead of breaking the interfaces, warnings are generated. These will stay there for some time, until we remove them entirely.

This changeset is now backwards compatible, but to get the new features (restrictions based on the registration authority) one needs to properly upgrade, by initializing the Policy object with a metadata store. Usage that involves loading the configuration through the saml2.config.Config object get this automatically (this includes, the saml2.server.Server (IdP) object and the saml2.client_base.Base and saml2.client.Saml2Client (SP) objects.)