add session_not_on_or_after

[pcaskey]

Sets the session_not_on_or_after parameter in downstream assertions
when appropriately configured.

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]

As mentioned on #207, you use a configuration option that is not declared anywhere, it is searched in the part of the configuration that belongs to pysaml2 but it is handled by satosa. This needs to be fixed.

Moreover, I'd like to find time to rework IdentityPython/pysaml2#518 so that we can have a base upon which we handle date/time. This could then be expressed by utilizing that functionality.

I'll keep this open in order to come back to it.

[pcaskey]

Thanks, Ivan. Unfortunately, I’m not sure how to fix the undeclared config option(s). Where would I do that? From: Ivan Kanakarakis <notifications@github.com> Sent: Tuesday, April 2, 2019 7:34 AM To: IdentityPython/SATOSA <SATOSA@noreply.github.com> Cc: Paul Caskey <pcaskey@internet2.edu>; Author <author@noreply.github.com> Subject: Re: [IdentityPython/SATOSA] add session_not_on_or_after (#206) As mentioned on #207<#207>, you use a configuration option that is not declared anywhere, it is searched in the part of the configuration that belongs to pysaml2 but it is handled by satosa. This needs to be fixed. Moreover, I'd like to find time to rework IdentityPython/pysaml2#518<IdentityPython/pysaml2#518> so that we can have a base upon which we handle date/time. This could then be expressed by utilization that functionality. I'll keep this open in order to come back to it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#206 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ANegn5lussWg--JVMTQ52QwQZBPO4epEks5vc05GgaJpZM4bjvjS>.

[c00kiemon5ter]

Unfortunately, I’m not sure how to fix the undeclared config option(s). Where would I do that?

Yep, this is common, and we must handle it in a way that is explicit what is what.

So, for example, I'm looking into the saml-backend configuration. The configuration has three parts:

• The base:

module: satosa.backends.saml2.SAMLBackend
name: Saml2
config:
[...]

You can think of this as "metadata" for the file. They are a fixed set of options that describe who is going to load and handle this file, what name it has, and what is the configuration that will be provided.

• The config for the module:

[...]
config:
  idp_blacklist_file: /path/to/blacklist.json

  # disco_srv must be defined if there is more than one IdP in the metadata specified above
  disco_srv: http://disco.example.com

  sp_config:
[...]

All options under config will be read by satosa. These options should change the way satosa works on top of pysaml2. sp_config and idp_config will be passed to pysaml2 directly - satosa doesn't really care about those options.

• The pysaml2 config

  sp_config:
    key_file: backend.key
    cert_file: backend.crt
    organization: {display_name: Example Identities, name: Example Identities Org., url: 'http://www.example.com'}
    contact_person:
    - {contact_type: technical, email_address: technical@example.com, given_name: Technical}
[...]

anything under sp_config and idp_config is handled by pysaml2; it is loaded and given directly to pysaml2 handlers. Those settings are used by pysaml2 to load an IdP (frontend) or an SP (backend). They are defined by pysaml2 and handled by pysaml2.

---

There is blurry line between what should be part of pysaml2 and what should be part of satosa. I am very skeptical of whether pysaml2 should be including runnable services, like an IdP, or whether it should be just a library with behaviour decided and given by its users (ie satosa).
For now, anything that affects a single entity (an SP or IdP) and not the internal transformation of the data given and received, should go to pysaml2.

What you do here though, is passing through an option to a pysaml2 utility, which I'd say is fine to do. What needs to change is either to move the option outside the pysaml2 config, or look into pysaml2 and see whether such functionality is already there and make use of it.