Hi all,
No worries (yet), this is not about issues we have uncovered.
We have the opportunity however to have a team from the GEANT project
review the code of SaToSa. We already had them do a review of the
InAcademia service itself, now they can look at the code.
Their question is however, which areas would be of most interest to look
at, as just starting at line 1 is probably not a good idea ;)
Could you also express why these code areas are most sensitive?
* My initial guess would be the code that handles incoming OIDC and
SAML is most critical (so the backends). Including the bits that do
validation of these requests.
* Next the code that handles business logic of interpreting the
internal state and make the responses out of that
* Then the frontends
Does that make sense? Should we also include looking into the libraries
deeply?
In addition are you aware of additional reviews that were performed? If
so we would be really interested to learn about these.
Ofcause we will share the finding in a confidential way. By the way,
does idpy have some contingency rules about that already?
Thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
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
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
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
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
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
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)
Hi all,
As part of operationalization the InAcademia service I have had to look
into the software licences and IPR of SaToSa, and its underlying
dependencies. Please find an overview below. The ones marked with a *
are included into idpy universe if I am correct, the others are
external. If you feel something is missing, or should not be in this
list, please let me know.
Based on that I have a few questions and observations:
*Licenses*
* It was not trivial for all components to find out the actual license,
especially for some of the dependencies, as licenses are not always
included. In several cases a license statement is included in the
meta-data of the pip package, but the actual license conditions are not
met. (like e.g. in the case of Apache2, a license file needs to be
delivered as part of the code). From a very puristic point of view that
would mean the software is actually not open source, and hence cannot be
used without a legal risk.
* For the software marked with * we do provide licenses and we do live
up to the conditions of the license :)
* License compatibility wise, we are doing well: all idpy related
software is apache2 licensed, and we do not seem to have dependencies
that outright conflict that license, apart from "chardet" which is LGPL
licenced. (I used this a a baseline:
https://www.apache.org/legal/resolved.html) While I do not think any of
us have the ambition to sell SaToSa as a product directly, I was
wondering if we should replace this with an alternative with a more
suitable license.
* Given the long list of dependencies, I must say I was wondering if we
do not have a little cleaning up to do.
*Copyright & IPR*
* For the idpy related software I note the copyright statements seem to
be missing or incomplete: I know for sure Roland has been working on
several components, but I suspect he has been doing so with multiple
hats on. However I e.g. do not see either GEANT project, UMEA or
NORDUnet copyright reflected, while I do see commits from GEANT project
members in the git history. I am wondering if we should rectify this,
especially in the light of the EU's sensitivity to being able to see
what their money was used for (we have had questions on that in previous
EC reviews of the GEANT project). I could also image a similar sentiment
with some of the NRENs and companies that contributed?
Comments and though are much appreciated!
Best,
Niels
python_editor Apache 2.0
alservice Apache 2.0 *
cmservice Apache 2.0 *
oic Apache 2.0 ?
pyjwkest Apache 2.0 *
pyop Apache 2.0 *
pysaml2 Apache 2.0 *
requests Apache 2.0
satosa Apache 2.0 *
vopaas Apache License 2.0 *
vopaas_statistics Apache License 2.0 *
pymongo Apache License, Version 2.0
pyopenssl Apache License, Version 2.0
babel BSD
beaker BSD
flask BSD
flask_babel BSD
flask_mako BSD
jinja2 BSD
markupsafe BSD
pycparser BSD
werkzeug BSD
alabaster BSD License
click BSD License
pycryptodomex BSD License
cryptography BSD or Apache License, Version 2.0
repoze.who BSD-derived (http://www.repoze.org/LICENSE.txt)
idna BSD-like
python_dateutil Apache License, Version 2.0
chardet LGPL
alembic MIT
asn1crypto MIT
banal MIT
cffi MIT
dataset MIT
future MIT
gunicorn MIT
mako MIT
normality MIT
paste MIT
pip MIT
pystache MIT
pytz MIT
pyyaml MIT
six MIT
urllib3 MIT
webob MIT
wheel MIT
setuptools MIT License
sqlalchemy MIT License
certifi MPL-2.0
decorator new BSD License
defusedxml PSFL
bson Apache License, Version 2.0
cryptodome BSD or Apache License, Version 2.0
gridfs Apache License, Version 2.0
itsdangerous BSD License
jwkest Apache License, Version 2.0
openssl OpenSSL License
past MIT License
pkg_resources BSD or Apache License, Version 2.0
saml2 Apache License, Version 2.0
yaml MIT License
zope.interface ZPL 2.1
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
