June 2018 - Idpy-discuss - lists3.sunet.se

by hlflanagan＠sphericalcowgroup.com

Hi all, One of the individuals I contacted when I was reaching out about the possibility of a [C]CLA pointed out the following from the GitHub Terms of Service: --- 6. Contributions Under Repository License Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms. If you have a separate agreement to license your contributions under different terms, such as a contributor license agreement, that agreement will supersede. Isn't this just how it works already? Yep. This is widely accepted as the norm in the open-source community; it's commonly referred to by the shorthand "inbound=outbound". We're just making it explicit. (https://help.github.com/articles/github-terms-of-service/) --- I've also reviewed the licenses listed under each of the Identity Python projects: * pySAML2 = Apache 2.0 * SaToSa = Apache 2.0 * pyXMLSecurity = NORDUnet (2 clause BSD) * pyFF = SUNET (2 clause BSD) * pyeleven = SUNET (2 clause BSD) My reading of this suggests that a CLA doesn't actually offer us any assurances we don't already have by a) using GitHub (and therefore agreeing to the ToS) and b) posting the licenses in the repos (which must be inherited by anyone posting in those repos, again thanks to the GitHub ToS). Thoughts or concerns? Heather

5 years, 7 months

5
9
0 0

Agenda: idpy developers meeting, 26 June 2018

by hlflanagan＠sphericalcowgroup.com

Date: Tuesday, 26 June 2018 Time: 06:00 PT | 09:00 ET | 15:00 GMT https://bluejeans.com/655841213 Agenda: 0. Agenda bash 1. särimner and Satosa (managing Satosa as a service) - how can SATOSA run behind a load balancer or with multiple gunicorn workers, as unsolicited-requests need to be shared between the processes - if there is a way to gracefully restart/reload SATOSA to load a new configuration 2. PR status - Satosa (Satosa PRs - https://github.com/IdentityPython/SATOSA) - Satosa microservices - pySAML (https://github.com/IdentityPython/pysaml2) - pyFF (https://github.com/IdentityPython/pyFF) 3. OIDC libraries - pyOIDC - fedOIDC* 4. Governance update and CLAs (or not) 5. AOB

5 years, 10 months

3
4
0 0

Date-Time issues

by ivan.kanak＠gmail.com

Hey everyone, TL:DR the world disagrees with the SAML2 spec regarding datetime representation. I've been looking over issue #445 https://github.com/IdentityPython/pysaml2/issues/445 The user is using some software that generates a date like this: 2017-08-29T09:16:45.0631274-05:00 and this cannot be parsed by pysaml2. Even if pysaml2 did parse this, internally it does not take into account the timezone information. This means that comparing two dates with different timezones will return incorrect results. Dates can appear in a lot of attributes in SAML, but they are all defined as of type `dateTime` datatype. This type is defined by XML Schema Part 2: Datatypes Second Edition: https://www.w3.org/TR/xmlschema-2/#dateTime However, SAML2-core on section 1.3.3 specifies that: > #### 1.3.3 Time Values > > All SAML time values have the type `xs:dateTime`, which is built in to the W3C XML Schema Datatypes specification [Schema2], and **MUST be expressed in UTC form, with no time zone component**. > > SAML system entities SHOULD NOT rely on time resolution finer than milliseconds. Implementations MUST NOT generate time instants that specify leap seconds. > Note that at this point there are three layers: - SAML2-core, section 1.3.3 - XML Schema Part 2: section 3.2.7: dateTime datatype definition - ISO-8601 spec Each layer says it does exactly what the layer below does .. but with some exceptions .. which usually make things *a lot* harder to manage. This means that for SAML2 the `dateTime` datatype is assumed to be in UTC and must not define a timezone. In the example case above, the correct value would be: 2017-08-29T14:16:45.063 Notice that the fractional seconds have been stripped to 3 decimal places to represent milliseconds (instead of 6 places which would mean microseconds). The original representation had 7 decimal places which means nanosecond precision which cannot be supported by the native python types; numpy defines datetime64 which has greater precision https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.datetime.html So.. the question now becomes whether implementations actually hold that promise, and if not, how do we handle it.. Looking around, all I can find is examples where dates are in the form: 2017-08-29T09:16:45Z that is, they include 'Z' which means 'UTC', or '+00:00' or '-00:00'. By including the timezone part they are invalid values. The only place where I see correct values is the Wikipedia examples: https://en.wikipedia.org/wiki/SAML_2.0 Looking at the history, these examples used to include 'Z', but have been fixed by the following changeset: https://en.wikipedia.org/w/index.php?title=SAML_2.0&type=revision&diff=5049… which correctly summarises the change as "Removed time-zone component from examples as this is prohibited (see section 1.3.3 of SAMLCore)". How do we solve this? ## Plan A: Follow the spec. Treat 'Z'-suffixed and other timezoned values as invalid. This will probably break many running setups, as it seems other implementations send dates including the 'Z'/UTC timezone suffix. (It is still an open question whether implementations send other timezoned values.) ## Plan B: Ignore the spec, assume XML Schema dateTime datatype and accept 'Z'-suffixed values (along other timezoned values.) This means things will continue as normal, but there is a case that we now need to handle; comparing timezoned dates with untimezoned dates. This is covered by the XML Schema spec in section 3.2.7.4 Order relation on dateTime and defines the incomparable cases https://www.w3.org/TR/xmlschema-2/#dateTime-order ## Plan C: Do our own thing? Make things worse? Treat untimezoned dates as UTC? I'm putting this here to see what everyone else has to say. I'd love to go with Plan-A :) (What's the point of a specification that none follows? I understand though, it is not a viable solution, at least at the moment.) In the meantime, I'll look into other implementations to figure out what they do. -- Ivan c00kiemon5ter Kanakarakis >:3

5 years, 10 months

4
7
0 0

idpy.org and https

by ivan.kanak＠gmail.com

idpy.org is hosted as a github-pages website (Jekyll SSG). GitHub Pages now support HTTPS for sites with custom domains through LetsEncrypt. Currently, idpy.org is using A records to point to github. The A record IPs have now changed and should be updated, in order to support https. Alternatively, we can set an ALIAS or ANAME record for idpy.org and be safe from future (IP) changes. If the DNS admins can look into that, it would be great ;) News item: https://blog.github.com/2018-05-01-github-pages-custom-domains-https/ Related help-center artile: https://help.github.com/articles/setting-up-an-apex-domain/ -- Ivan c00kiemon5ter Kanakarakis >:3

5 years, 10 months

2
2
0 0

encrypting responses

by skoranda＠gmail.com

Hi, I think I have asked this before but I do not recall if I received a definitive answer... Does the pysaml2 IdP object (and therefore SATOSA) support sending an encrypted SAML response to the SP? If so, what is the configuration option(s)? Thanks, Scott K

5 years, 10 months

2
4
0 0

No call on 12 June, but ...

by hlflanagan＠sphericalcowgroup.com

Hi all, This is a reminder that we're not having a call tomorrow. However, for those folks on the list who are here, we can perhaps find a time. Here's a poll to find us an hour to meet: https://doodle.com/poll/rbmbwc2wa8vauh7h -Heather

5 years, 10 months

1
2
0 0

Moving repos

by roland＠catalogix.se

Hi guys, OIDF has agreed to host the OIDC libraries that I helped Google build. They also understand that they must fund the maintenance of the libraries. To make it more concrete they want the Python packages (which are the only one that are done) to be moved to the OIDF GitHub site within the next couple of weeks. This means that the cryptojwt, oidcmsg, oidcservice and oidcrp repos will be moved away from IdentityPython. I people don’t disagree I’d like to keep the OP side repo oidcendpoint and oidc-op (not there yet) at IdentityPython. And of course all the repos that has to do with OIDC identity federations. — Roland The higher up you go, the more mistakes you are allowed. Right at the top, if you make enough of them, it's considered to be your style. -Fred Astaire, dancer, actor, singer, musician, and choreographer (10 May 1899-1987)

5 years, 10 months

2
4
0 0

Meeting reminder: idpy dev call, 29 May 2018

by hlflanagan＠sphericalcowgroup.com

Date/Time: Tuesday, 29 May 2018 @ 06:00 UTC-7 | 09:00 UTC-4 | 15:00 UTC+2 BlueJeans link: https://bluejeans.com/655841213 Agenda 0. Administrivia - governance status - side meeting during TNC2018? 1. Satosa - https://github.com/IdentityPython/SATOSA/pulls 2. pySAML2 - https://github.com/IdentityPython/pysaml2/pulls 3. pyFF - https://github.com/IdentityPython/pyFF/pulls 4. Other repositories (depending on who's on the call)

5 years, 10 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss June 2018