Hi Leif,
I added 2 pipes to buildin.py:
- publish_html creates static HTML views of IDPs and SPs, using XSLT based on Peter Schober’s alternative to MET;
- publish_split: similar to store, but added validUntil and creates signed XML-file per EntityDescriptor. This can be consumed dynamically by ADFS in an IDP role.
I put it directly into buildin.py because it shares some code with the sign pipe. Is this viable from your PoV - if yes, I would make an PR.
Cheers, Rainer
Hi all,
being part of Commons Conservancy brought up yet another subject,
which is whether we should add a header with license information in
every file in the projects under idpy. This is not something done in
an abstract way, there is a specific format modelling this information
(see https://spdx.org/ and https://reuse.software/ - more specifically
https://reuse.software/practices/2.0/) Still, I find it problematic.
We want to open up the question to the wider community and consider
their thoughts on this. The forwarded message below is discussing this
subject. You can see the question we posed, the answer we got and my
comments. Feel free to tell us what you think on this.
---------- Forwarded message ---------
Date: Thu, 16 May 2019 at 09:56
> ---------- Forwarded message ----------
> Date: May 8, 2019, 8:15 AM -0700
>
> > Why does CC think having a single license file per project is
> > insufficient? Our thought is that if we can avoid adding a header to
> > every single file, that would be nice, esp. given we already have this
> > info in the license file and we have the Note Well.
>
>
> this is not just our opinion, but something that is an industry and
> community standard for legal compliance these days. When companies like
> Siemens, Samsung or Honeywell use some code in one of the hundreds or
> thousands of devices and systems in their product line, they need to be
> able to provide the correct license and a download of the exact version.
> This means machine readability too.
>
I've actually observed the opposite of that. Communities abandon the
"license in every file" model, and just use a single LICENSE file in
the root of the project. The LICENSE file contains license
information, that is, it is not a single license but it has exception
sections and so on.
> To quote from https://reuse.software/practices/2.0/ :
>
> Scroll to the section "2. Include a copyright notice and license in each
> file"...
>
> "Source code files are often reused across multiple projects, taken from
> their origin and repurposed, or otherwise end up in repositories where
> they are separate from its origin. You should therefore ensure that all
> files in your project have a comment header that convey that file’s
> copyright and license information: Who are the copyright holders and
> under which license(s) do they release the file?
>
Continuing from above, the standardization of package-management
formats and tools has helped exactly with that: to avoid distribution
of single files, and instead provide packages and modules. It is bad
practice and considered a hack to copy files. Nobody liked that model
and everyone is moving away; it is unstructured, it becomes
unmanageable and it will cause problems.
> It is highly recommended that you keep the format of these headers
> consistent across your files. It is important, however, that you do not
> remove any information from headers in files of which you are not the
> sole author.
>
> You must convey the license information of your source code file in a
> standardised way, so that computers can interpret it. You can do this
> with an SPDX-License-Identifier tag followed by an SPDX expression
> defined by the SPDX specifications."
>
> (the text goes on for a while after this, to clarify the point but this
> is the basic gist of it)
>
> There is a nice Python tool to check:
>
> https://github.com/fsfe/reuse-tool
>
> I hope this makes sense
>
Well, it does not make complete sense. We're talking about licensing a
project. A project is not just code; there are data files (html, xml,
yaml, json files), binary files (archives/zip, images, audio, video,
etc), text files (configs, ini-files, etc) all "not-code". How do you
mark those files? Does the LICENSE file need a license-header? The
json format does not define comments, how do you add a header there?
If a binary file does not get a license header, why should a file with
code get one?
I would expect there to be a way to have the needed information
unified. If the files themselves cannot provide this information it
has to be external; thus the LICENSE file. If someone is worried about
somebody else re-using single files that do not have license
information (a python file, a png image, etc) there is really nothing
you can do (the DRM industry has been trying to solve for a long time;
and still your best bet is "social DRM").
Since, we're developing on open source with a permissive license, even
if someone does that, should we be happy that someone is actually
using what we built or sad that the files they copied did not have a
license header? And if they include the license information of that
copied file in their project's LICENSE file, is this solved?
Having pointed these contradictions, I am thinking that the "license
in every file" model seems to be a step backwards. It is introducing
overhead and does not really solve the problem, while at the same time
it enables a culture of bad practice (copying files around).
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
Hello,
My name is Felipe Cardoso and I am part of the IT team at LIneA
(Interinstitutional e-Astronomy Laboratory). LIneA is a non-profit
organization that operates in the international academic ecosystem,
supporting Brazilian participation in astronomical surveys and managing
large volumes of data.
Currently, our infrastructure includes services that are integrated with
authentication mechanisms such as social login (Google, Github, CILogon)
and federated login (SAML) through an instance of the SaToSa proxy. In our
case, we have some services that implement SAML, and thus we use the SAML
Mirror frontend plugin to allow the mentioned authentication backends to
serve the services' users.
We would like to implement the concept of Single Sign-On (SSO) in our
services, but we are facing challenges due to our limited knowledge of
SaToSa. Could you please inform us if it is possible to configure SSO
functionality in SaToSa? Additionally, is there anyone with a similar
scenario to ours who could provide guidance on the way forward?
Felipe on behalf of LIneA IT Team
*Idpy meeting 11 June 2024*
Attendees: Johan L, Shayna, Ivan
0 - Agenda bash
1 - Project review
a. General -
b. OIDC libraries - https://github.com/IdentityPython (idpy-oidc,
JWTConnect-Python-CryptoJWT, etc)
- Roland has opened an PR - it fails one of the tests
- https://github.com/IdentityPython/idpy-oidc/pull/104
- https://github.com/IdentityPython/idpy-oidc/issues/106
- A claim that is expected to be returned is not coming back
anymore.
- Not understanding why this is happening
- Is the test actually a requirement of the spec, or just
something the test assumed would be there?
- This PR addressed changes required to align with the PAR (Pull
Authorization request) rfc
- RAR (Rich Authorization request) allows you to define more
things happening during the authorization phase
- Have pinged Roland but haven't heard back. If Ivan has time he
can also look into this.
- New PR - https://github.com/IdentityPython/idpy-oidc/pull/107
- Allowing variable ports for native oidc clients or RPs when the
redirect uri is the literal localhost - the actual IP ( IPv4
127.0.0.1 or IPv6 ::1 / 0:0:0:0:0:0:0:1)
- spec says native clients, when they start an authorization flow,
they do this through the loopback interface and bind to 127.0.0.1
/ ::1 and can use any port available. The port is decided
directly by the
platform and the client does not have control of that.
- requests are forwarded to the auth server with the port assigned
by the system
- This PR allows variable port exception for native clients
- introduces checks around redirect uris - they become part of the
location header - they are URLs and not uris. They can have
other schemes.
The python library doesn't do certain validations so they
have to be done
manually around this uri (which is a URL) - scheme:
path/domain/valid port.
- This PR bound to http URLs
- There is further work to be done to filter out certain schemes
for the redirect uri that wouldn't make sense in this case
and could be
dangerous. Ivan will make an issue for this.
c. Satosa - https://github.com/IdentityPython/SATOSA
- Ivan is supposed to create a new release-hasn't done yet.
- Matthew needs to update image around missing SAMLtest ID - he's
probably waiting for Ivan's new release
- updates on pyop to start deprecating-
https://github.com/IdentityPython/pyop/pull/55 -
https://github.com/IdentityPython/SATOSA/issues/445
- pyop provides interfaces that are useful also for SATOSA.
Support was added in pyop for stateless flows - all the
state kept in
tokens. There are limitations to this - there is a size
limit - but it does
allow no need for a db and keeping state. Another drawback
is you can't
tell when token has been revoked.
- when the code was introduced it broke another part, having to
do with the claims from the user info endpoint.
- Fix is to bring back the old flow and make an exception when
in the stateless mode.
- this MR will be merged and new pyop released but really pyop
should be deprecated. There should be amendments to the
Readme pushing
people toward idpy-oidc. Already have a SATOSA backend
using idpy-oidc.
Don't have support for a frontend using idpy-oidc. There
is the work
Giuseppe has done which we already point to. We are not
removing pyop but
saying that the focus is somewhere else.
d. pySAML2 - https://github.com/IdentityPython/pysaml2
- Johan's PR - https://github.com/IdentityPython/pysaml2/pull/964
- Big divide in security domain
- make things configurable - this is what xml dsig/encryption is
about - but as you interoperate with others it makes
updating difficult.
- OR everything should be pinned down to very specific things -
no random lengths of keys, no random types of keys, no
random algorithms
etc. Everything is specified and there is only one way to
do things. If you
pick the right things, you are future-proof. This is what
signal is about.
- Add xenc schema 11 to code base.
- pysaml2 added support for xmlsec binary
- frederik's MR about typing is related to this -
https://github.com/IdentityPython/pysaml2/pull/897
- Ivan will merge Johan's PR (964 - need to also check whether
anything is needed to support newer version of xmlsec1) and
make a release,
then merge PR 897 to unblock Johan, then get back to 961
adding support for
xmlsec module https://github.com/IdentityPython/pysaml2/pull/961
- Also need to make sure xmlsec module doesn't need lxml
- a few annoying things: xmlsec module defines its own types for
handling keys and certificates, then there is another type we
define based
on pyOpenSSL, then there is another type from
pyca/cryptography - just keep
having to convert from one type to another.
- xmlsec1 - C libraries - had to provide specific constraints to
restrict xmlsec from going out to the web to fetch keys or metadata or
other interfaces to do calculations. Ivan is pretty sure
xmlsec module is
doing the same thing,
- also would use signing key from within the SAML response itself
instead of key extracted from the metadata
- We have tests for the binary - make sure they also work with
xmlsec module, then limit functions in code
-
e. Any other project (pyFF, djangosaml2, pyMDOC-CBOR, etc)
- work on pyff around supporting trustinfo elements - spec stems from
seamlessaccess - they indicate certain IdPs are preferred over the rest -
you can say you only want to select from those - they can be
highlighted or
ranked first, for example. There can be complex rules indicating
preference
of sets based on assertion authorities or other things.
2 - AOB
- Ivan will be away 25 June. Will check with Roland for his availability
and determine if meeting will happen.
