Introduce new configuration option `entity_attributes` that defines a list of
dictionaries each of which represents an <Attribute> element. Each dicrionary has fields
for the NameFormat, the Name, the FriendName and a list of strings that are used to
create <AttributeValue> elements, each with the string as the text node.

    "entity_attributes": [
      {
        "name_format": "urn:oasis:names:tc:SAML:2.0:attrname-format:uri",
        "name": "urn:oasis:names:tc:SAML:profiles:subject-id:req",
        # "friendly_name" is not set
        "values": ["any"],
      },
    ]

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

The `name_id_format` configuration option is used to define

1. the value of the `<NameIDFormat>` metadata element
2. and the value of the `<NameIDPolicy>` `Format` attribute in an `AuthnRequest`

The configuration option to set what the value of `<NameIDFormat>` element is in the
metadata should be different from the configuration option to specify what should be
requested in an `AuthnRequest` through the `<NameIDPolicy Format="...">` attribute.

Introduce a new option (`name_id_policy_format`), or use the same name but scoped in a
specific section for metadata and AuthnRequest.

On the side of this, pysaml2 defaults to _transient_ as the `<NameIDPolicy
Format="...">` attribute value. To omit requesting a value for the `<NameIDPolicy
Format="">` attribute the value `"None"` (a string) must be set in the configuration.
This is unintuitive. It is better to be explicit and set transient to request a
transient NameID, than not setting a value and requesting transient by default. If no
value is set, no specific `<NameIDPolicy Format="...">` should be requested.

- Refactor the name_id_format usage
- Add name_id_policy_format configuration option
- Remove the "None" convention value

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

Add requested_attributes param to create_authn_request

We need to know _the name of the attribute_ that represents the identifier of the node
that is being signed, or encrypted, or verified. We guess the name -by trying `ID`, `Id`
and `id`- and pass it to `xmlsec1` using the `--id-attr` command line option.

_Why is this needed?_ Shouldn't the attribute names be specified by the corresponding
specifications? Let's look into the specs to find out.

* saml-core:
  * `StatusResponseType` uses `ID`
  * `RequestAbstractType` uses `ID`
  * `Assertion` uses `ID`

* xmldsig-core:
  * `SignatureType` uses `Id`

* xmlenc-core:
  * `EncryptedType` uses `Id`

So, the answer is _yes_ - the attribute names are defined and, instead of guessing, we
should be passing in the id-attribute names as defined by the specs.

_Note_: But, do we even need to do this? If the names are standardized, why do we bother
with this? In fact, the manual for `xmlsec1` explicitly says that

    --id-attr[:<attr-name>] [<node-namespace-uri>:]<node-name>

        adds attributes <attr-name> (default value "id") from all nodes
        with<node-name> and namespace <node-namespace-uri> to the list of
        known ID attributes; this is a hack and  if you can use DTD or schema
        to declare ID attributes instead (see "--dtd-file" option), I don't
        know what else might be broken in your application when you use this
        hack

However, it seems that `xmlsec1` by default will only look for an attribute with name
`id`. The right way to solve this is to pass in a DTD file. Then, `xmlsec1` will
understand that it needs to look up a different attribute name. Unfortunately, there are
no official DTDs (or even unofficial, to my knowledge) for SAML. The SAML specifications
instead provide XSD files. Even though `xmlsec1` mentions _schema_, there doesn't seem
to be a way to pass in an XSD file. So, we have to resort to this "hack".

When we sign a document, we need to point to the node that will be signed. The nodes
that we are signing are always SAML nodes (Assertion, StatusResponseType (Response,
etc), RequestAbstractType (AuthnRequest, etc)). All SAML nodes that will be signed use
`ID` as the attribute name. So, in order to sign and verify a signature, we need to pass
in `ID`.

When encrypting a document, we need to point to the node whose content will be
encrypted. Currently, we use XPath to point to that node, without the use of an id. But,
we could be using an identifier to locate the node, and if we did so, we would still be
using `ID`.

When decrypting a document, we need to point to the node that contains the encrypted
data. This is where things change. Since the SAML node itself is encrypted we cannot
point to an `ID` attribute, as we did in the other cases. Instead, it is specified that
a node named `EncryptedData` exists, that may have an `Id` attribute. This is where we
want to point to. So, we need to use `Id`.

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

```
************* Module saml2.config
src/saml2/config.py:464:23: E1135: Value '_logconf' doesn't support membership test (unsupported-membership-test)
src/saml2/config.py:466:27: E1136: Value '_logconf' is unsubscriptable (unsubscriptable-object)
src/saml2/config.py:481:50: E1136: Value '_logconf' is unsubscriptable (unsubscriptable-object)
src/saml2/config.py:486:22: E1120: No value for argument 'filename' in constructor call (no-value-for-parameter)
src/saml2/config.py:488:23: E1135: Value '_logconf' doesn't support membership test (unsupported-membership-test)
src/saml2/config.py:489:42: E1136: Value '_logconf' is unsubscriptable (unsubscriptable-object)
src/saml2/config.py:505:43: E1136: Value '_logconf' is unsubscriptable (unsubscriptable-object)
src/saml2/config.py:552:19: E1136: Value 'self.virtual_organization' is unsubscriptable (unsubscriptable-object)
```

this seems right; the operations upon the Logger object do not make sense.
There is no need to "fix" this, we just remove the relevant code.
We should come back to this and refactor how the logger is configured for the library.

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

Test for compile warning using:

    find src/ -iname '*.py' | xargs -P 4 -I{} python -Wall -m py_compile {}
    find tests/ -iname '*.py' | xargs -P 4 -I{} python -Wall -m py_compile {}

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>

PySAML2 did not check that the signature in a SAML document is enveloped and thus
XML signature wrapping (XSW) was effective.

The signature information and the node/object that is signed can be in different places
and thus the signature verification will succeed, but the wrong data will be used. This
specifically affects the verification of assertions that have been signed.

This was assigned CVE-2020-5390

Thanks to Alexey Sintsov and Yuri Goltsev from HERE Technologies to report this.

+ + + + + + + +

In more detail:

libxml2 follows the xmldsig-core specification. The xmldsig specification is way too
general. saml-core reuses the xmldsig specification, but constrains it to use of
specific facilities. The implementation of the SAML specification is responsible to
enforce those constraints. libxml2/xmlsec1 are not aware of those constraints and thus
process the document based on the full/general xmldsig rules.

What is happening is the following:

- xmldsig-core allows the signature-information and the data that was signed to be in
  different places. This works by setting the URI attribute of the Reference element.
  The URI attribute contains an optional identifier of the object being signed. (see
  "4.4.3 The Reference Element" -- https://www.w3.org/TR/xmldsig-core1/#sec-Reference)
  This identifier is actually a pointer that can be defined in many different ways; from
  XPath expressions that need to be executed(!), to a full URL that should be fetched(!)
  in order to recalculate the signature.

- saml-core section "5.4 XML Signature Profile" defines constrains on the xmldsig-core
  facilities. It explicitly dictates that enveloped signatures are the only signatures
  allowed. This mean that:
  * Assertion/RequestType/ResponseType elements must have an ID attribute
  * signatures must have a single Reference element
  * the Reference element must have a URI attribute
  * the URI attribute contains an anchor
  * the anchor points to the enclosing element's ID attribute

xmlsec1 does the right thing - it follows the reference URI pointer and validates the
assertion. But, the pointer points to an assertion in another part of the document; not
the assertion in which the signature is embedded/enveloped. SAML processing thinks that
the signature is fine (that's what xmlsec1 said), and gets the assertion data from the
assertion that contains the signature - but that assertion was never validated. The
issue is that pysaml2 does not enforce the constrains on the signature validation
facilities of xmldsig-core, that the saml-core spec defines.

The solution is simple; all we need is to make sure that assertions with signatures (1)
contain one reference element that (2) has a URI attribute (3) that is an anchor that
(4) points to the assertion in which the signature is embedded. If those conditions are
met then we're good, otherwise we should fail the verification.

Signed-off-by: Ivan Kanakarakis <ivan.kanak@gmail.com>