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 everyone,
there has been a report on incident-response at idpy.org about a security
issue in PySaml2.
Alexey Sintsov and Yuri Goltsev from HERE Technologies reached out and
reported a XML Signature Wrapping (XSW) vulnerability. The issue
affects responses with signed assertions. PySaml2 can be tricked to
think that an assertion had been signed and use the assertion
information, when in reality the Signature points to another part of
the xml document that is controlled by another party.
The issue was assigned CVE-2020-5390 and is now fixed in the latest
pysaml2 release.
The relevant code commit that fixes is the issue:
https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521…
Release v5.0.0 contains more changes, including:
- Add freshness period feature for MetaDataMDX
- Fix ipv6 validation to accommodate for addresses with brackets
- Fix xmlsec temporary files deletions
- Add method to get supported algorithms from metadata
- Add mdstore method to extract assurance certifications
- Add mdstore method to extract contact_person data
- Start dropping python2 support
Pointers to the release with changelog and more information, below:
- the relevant release commit:
https://github.com/IdentityPython/pysaml2/commit/f27c7e7a7010f83380566a219f…
- the github release:
https://github.com/IdentityPython/pysaml2/releases/tag/v5.0.0
- the pypi package:
https://pypi.org/project/pysaml2/5.0.0/
+ + + + + + + +
In more detail, regarding the XSW vulnerability:
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.
--
Ivan c00kiemon5ter Kanakarakis >:3
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
Attendees:
Heather, Johan, Roland, Ivan, Scott K
Notes:
1 - Administrivia
a. Outcomes from idpy strategic developers meeting (Notes HERE)
We want to look at the new SSI space, including VCs, credential issuance, verifiable presentation. The idea is that we can turn the proxy into a verifier; it has to be the proxy since each member state may have their own implementation. We'll have to map out the different specifications we need to build against, how they tie together, understand what other groups are doing, and what reference implementations are coming out. From there, we come up with a set of projects we can implement. See new slack channel #oidc4uc.
What does this mean for the work underway for the existing projects? Are we done with big changes there such that we can focus on the bigger work in the SSI space? pySAML2 still needs cleanup on the config and what algorithms are used. We also still need to determine how we deal with attributes; we're using the friendly name internally but that might not be the right thing. Another chunk of work is replacing xmlsec1. SUNET intends to hire another developer who should be able to help with this, and Kushal will work on these as well.
For Satosa, there is more work to do there as well (see strategic developers meeting notes).
Ivan will lay out what needs to be built so we have an estimate of what resources will be required.
b. Summer call scheduling
Ivan will be gone from 25 July through 7 August. We will cancel the call on the 26th. Johan will miss the 9 August call.
2 - GitHub review
a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc)
Recent focus has been on the federation spec. There is still some work to do, but Roland and Vladimir will start working on some informal interop tests.
b. Satosa - https://github.com/IdentityPython/SATOSA
A minor patch release is coming out that defines the minimum version we need of pyop. For people installing new packages, this isn't a problem as the build will always pull in the latest. For people upgrading, it might have caused problems. This release also updates the ORCID integration.
Expect a bigger change in the next few weeks, including some changes from Giuseppe and pointing to the new image provided by Matthew. Also considering updates to the LDAP microservice; the new code needs tests.
c. pySAML2 - https://github.com/IdentityPython/pysaml2
There are three new commits: one that handles an exception thrown by Satosa, the next regarding the registration information, and last the addition of the voPerson class using voPerson 2.0.
Future release will update the code style; this will be documented.
Ivan is experimenting with poetry; will use it for Satosa first and then see how to use it for a library like pySAML2. (Note that poetry is already being used for cryptojwt.) Also looking at https://github.com/sissaschool/elementpath. This is a helper library that will help us move away from xmlsec1.
We also need to take care of the canonicalization algorithms. This also uses lxml, which is another piece required to get us away from xmlsec1.
Request to consider whether we can call out to a different library that would provide the functionality of xmlsec1, something derived from the Shibboleth project? Not ideal because we'd be relying on a big chunk of Java code, but it might be a viable option. Probably will never be the default option.
d. Any other project (pyFF, djangosaml2, etc)
3 - Discussion
At TNC, there was discussion re: moving idpy under a well-known framework (e.g., flask, fastapi, django). Also talked about changing the storage backend (cookies, databases, other). If anyone has opinions on those topics, please discuss on slack or the mailing list.
Regarding the framework, Ivan leans towards something lightweight (which would basically be flask or fastapi). It's also easier to migrate to another framework later if we choose one of these.
Thanks! Heather
Thanks! Heather
---------- Forwarded message ----------
From: Mario Loffredo <mario.loffredo at iit.cnr.it>
Date: Nov 8, 2021, 12:59 PM -0800
To: Hollenbeck, Scott <shollenbeck=40verisign.com at dmarc.ietf.org>, regext at ietf.org <regext at ietf.org>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-08.txt
> Hi folks,
>
> I think the first point we need to discuss is if we should introduce two
> conformance tags for this extension:
>
> - "rdap_openidc_level_0" used by RDAP servers to signal that they
> implement SSO through the OIDC services provided by a local OP
>
> - "rdap_federation_level_0" used by RDAP servers to signal that they
> implement SSO through the OIDC services provided by a set of trusted
> external OPs
>
>
> To start a SSO session with a server that is rdap_openidc_level_0
> conformant, an end user operating through a web browser:
>
> - sends a query to /tokens endpoint of the RDAP server without the id
> parameter
>
> - is authenticated by the local OP (i.e. by filling out the login form)
>
> - receives the access_token and uses it as either bearer or query
> parameter for submitting requests towards standard endpoints of the RDAP
> server
>
> - requests for token refreshment and revoking without including the id
> parameter
>
> In this scenario, the id parameter is ignored.
>
> To start a SSO session with a server that is rdap_federation_level_0
> conformant, an end user operating through a web browser:
>
> - sends a query to /tokens endpoint of the RDAP server including the id
> parameter
>
> - is authenticated by the OP discovered through the OpenID Discovering
> process (i.e. by filling out the login form)
>
> - receives the access_token and uses it as either bearer or query
> parameter for submitting requests towards standard endpoints of the RDAP
> server
>
> - requests for token refreshment and revoking including the id parameter
>
> In this scenario, the id parameter is required.
>
>
> Some futher considerations support my proposal of splitting the
> conformance in two:
>
> 1) AFAIK, the available OPs provide built-in OIDC features supporting
> the implementation of the Authorization Code Flow. But this doesn't
> apply for the features required to implement federation such as OP
> discovery and dynamic client registration. Therefore, while SSO could be
> implemented without knowing OIDC in depth, RDAP developers on server
> side should tackle the implementation of a federation at a lower level.
>
> 2) Joining a federation doesn't only imply the implementation of such
> additional OIDC features but also an agreement between all the parties
> involved as it is described in
> https://openid.net/specs/openid-connect-federation-1_0.html
> <https://openid.net/specs/openid-connect-federation-1_0.html>. For this
> reason, it seems to me that a federation represents a layer upon the
> implementaion of OIDC to support authentication and SSO.
>
> 3) Currently, some OPs provide support external authentication through
> other mechanisms (e.g identity brokering, social login). Briefly,
> instead of discovering the OP from a user identifier, the user is
> directly requested to select in a list of trusted OPs the one which will
> be in charge of the authentication.
>
> Hope it could be helpful to move the discussion forward.
>
> Best,
>
> Mario
>
>
> Il 08/11/2021 13:54, Hollenbeck, Scott ha scritto:
> > > -----Original Message-----
> > > From: I-D-Announce <i-d-announce-bounces at ietf.org> On Behalf Of
> > > internet-drafts at ietf.org
> > > Sent: Monday, November 8, 2021 7:45 AM
> > > To: i-d-announce at ietf.org
> > > Cc: regext at ietf.org
> > > Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-08.txt
> > >
> > > Caution: This email originated from outside the organization. Do not click links
> > > or open attachments unless you recognize the sender and know the content
> > > is safe.
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > > This draft is a work item of the Registration Protocols Extensions WG of the
> > > IETF.
> > >
> > > Title : Federated Authentication for the Registration Data Access
> > > Protocol (RDAP) using OpenID Connect
> > > Author : Scott Hollenbeck
> > > Filename : draft-ietf-regext-rdap-openid-08.txt
> > > Pages : 25
> > > Date : 2021-11-08
> > >
> > > Abstract:
> > > The Registration Data Access Protocol (RDAP) provides "RESTful" web
> > > services to retrieve registration metadata from domain name and
> > > regional internet registries. RDAP allows a server to make access
> > > control decisions based on client identity, and as such it includes
> > > support for client identification features provided by the Hypertext
> > > Transfer Protocol (HTTP). Identification methods that require
> > > clients to obtain and manage credentials from every RDAP server
> > > operator present management challenges for both clients and servers,
> > > whereas a federated authentication system would make it easier to
> > > operate and use RDAP without the need to maintain server-specific
> > > client credentials. This document describes a federated
> > > authentication system for RDAP based on OpenID Connect.
> > [SAH] Folks, this update includes some significant changes that were designed to align the specification more closely with both OpenID Connect and the web services architecture. For example, the ID of the query requestor can now be sent to the server in an HTTP authorization header OR a query parameter. The token management bits were also changed to include a refresh token in the /tokens response. Thanks to Mario Loffredo for the suggestions included in this update.
> >
> > Mario had some other suggestions that I haven't yet implemented. I encouraged him to share them with the list so we could have a broader discussion. Mario, please start that discussion at your convenience.
> >
> > Direct link to diff:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-openid-08
> >
> > Scott
> >
> > _______________________________________________
> > regext mailing list
> > regext at ietf.org
> > https://www.ietf.org/mailman/listinfo/regext
>
> --
> Dr. Mario Loffredo
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: http://www.iit.cnr.it/mario.loffredo
>
> _______________________________________________
> regext mailing list
> regext at ietf.org
> https://www.ietf.org/mailman/listinfo/regext
just cut pyFF 2.0.0 - its up on pypi and github.com/SUNET/docker-pyff has been updated to support building 2.0.0. The most important difference is of course that 2.0.0 has undergone extensive cleaning. All frontend applications - ie the admin UI and discovery service - have been given their own separate projects and pyFF is now an API server first and foremost. The admin UI is called github.com/SUNET/mdq-browser and the DS is famously become github.com/TheIdentitySelector/thiss-js from the seamlessaccess.org project.
Over the next few days I will spend some time updating the documentation - which has become a bit out of date - esp with more examples to illustrate a lot of the features that are part of pyFF but are sometimes less well known.
Another news for 2.0.0 is that support for python before v 3.7 has been dropped.
Thanks! Heather
As described in the Statues of IdentityPython [1], roughly half the seats for the idpy Board are opening for nominations. The following members have completed their one-year terms:
Ivan Kanakarakis (current chair)
Mike Jones
Chris Whalen
Roland Hedberg (at-large)
They are all eligible to be nominated again for a new board term.
The term for these seats is now shifting to a two-year cycle, such that half the board will be up for nomination each year.
Participants on the idpy-dev list act as the nominating committee for the idpy board. If you would like to nominate someone (or self-nominate) please contact me directly no later than 24 January 2020.
b. March 23 Hackathon/Workshop in Stockholm
Also, there will be a (small) f2f meeting at TIIME in Vienna.Will talk about how things are now, and where the platforms might go.
Suggest having a workshop style meeting on the 23rd. It is a more specific audience given they will be there about eduGAIN. Will build the list of things to work on during the TIIME meeting. Will have to allow for some flexibility on site. In general, topics will definitely include Satosa, pySAML2, pyFF, OIDC libraries
Next steps: Heather to set up registration, send an announcement, and start a wiki page of topics.
2. OIDC Federation update
a. Second Implementer’s Draft of OpenID Connect Federation Specification Approved <https://openid.net/2020/01/08/second-implementers-draft-of-openid-connect-f…>
No one voted against (yay!). There were some discussions at TechEx on things to add to the specification; that will happen now that this version fo the draft is approved.
There are plans for several interop workshops this year; could possibly run this in parallel to the idpy workshop, or some other time during the Town Hall. There will also be interop testing during TNC20. Still in discussion re: NORDUnet and/or IIW. There are currently 3 implementations ‘in the wild’.
b. Repository status
Waiting to hear from Mike Jones (OIDF) on whether they are okay with moving the repositories out from under OIDF.
3. GitHub review
a. OIDC implementations
(See above)
b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA>
Ivan will be making a new release for Satosa to account for the new pySAML2 release (to include a hint for the dependencies). There will also be an update to the version of the LinkedIn API that we use It should be compatible to the previous one. Also an update to allow the proxy to be a URL path. See:
https://github.com/IdentityPython/SATOSA/pull/279 <https://github.com/IdentityPython/SATOSA/pull/279>
https://github.com/IdentityPython/SATOSA/pull/280 <https://github.com/IdentityPython/SATOSA/pull/280>
https://github.com/IdentityPython/SATOSA/issues/179 <https://github.com/IdentityPython/SATOSA/issues/179>
Next on the list: work on logging. Need to make some change there, and this will eventually happen across all libraries. Ivan to coordinate with Hanna Sebuliba and Scott Koranda offline.
c. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2>
There is a new release for pySAML2 that includes a security fix. See email from Ivan on 13 January 2020, Subject " [Idpy-discuss] PySaml2 v5.0.0 - Security release"
Alexey Sintsov and Yuri Goltsev from HERE Technologies reached out and
reported a XML Signature Wrapping (XSW) vulnerability. The issue
affects responses with signed assertions. PySaml2 can be tricked to
think that an assertion had been signed and use the assertion
information, when in reality the Signature points to another part of
the xml document that is controlled by another party.
The issue was assigned CVE-2020-5390 and is now fixed in the latest
pysaml2 release.
The relevant code commit that fixes is the issue:
https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521… <https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521…>
Changes include an introduction of a new test file that tests handling of unknown elements. The vulnerable use cases are when you have signed assertions but unsigned responses.
Note: we should probably revise the incident handling procedure. It needs to be simplified (it currently has Ivan talking to himself at different stages). We should also discuss how to announce these security events. Should we warn the community that a security vulnerability has been found, and tell them when we’re going to do the announcement? Yes.
Apart from the security fixes, there are a handful of other changes. They are breaking changes (thus the new major number). In the future, security changes and breaking changes should not be included in the same release if possible. In this case, though, the security change is itself something of a breaking change, and it plus the other (small) breaking change were not too major a set of changes.
Reminder that we are not back porting security fixes. If others want to work on that, they can create branches.
d. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF>
Heather will ask Leif to send out an update.
4. AOB
Our next call is 21 January 2020; note that the second half overlaps the eduGAIN Baseline Maturity call, so people may drop off early.
2) These all are easy pull requests that can be easily merged after a fast revision, b) d) and e) are pure bugfixes:
a) ldap_store refactor: https://github.com/IdentityPython/SATOSA/pull/252 <https://github.com/IdentityPython/SATOSA/pull/252>
Will merge. This is mainly a discussion between Pepe and Scott.
b) Cookie state exception fix/workaround: https://github.com/IdentityPython/SATOSA/pull/250 <https://github.com/IdentityPython/SATOSA/pull/250>
Will merge.
c) multiple user_id: https://github.com/IdentityPython/SATOSA/pull/222 <https://github.com/IdentityPython/SATOSA/pull/222>
Could also do this via a microservice; may have one that already does this. Ivan will let Pepe know; having an example in this PR before closing would be helpful.
d) sign_alg/digest_alg policy fix: https://github.com/IdentityPython/SATOSA/pull/216 <https://github.com/IdentityPython/SATOSA/pull/216>
There is a similar PR on pySAML2 about introducing these options. (It was easier in Satosa.) Could map this to different configuration options to the backends, but would then need to map everything. It’s still a question on how to handle the different configurations between pySAML2 and Satosa.
Will merge this now, and when we have support in pySAML2 code, we can drop this from Satosa. Will still need to work on generalizing this.
e) selectagle dig/sign algs in backends: https://github.com/IdentityPython/SATOSA/pull/214 <https://github.com/IdentityPython/SATOSA/pull/214>
The previous one (216) is a bug fix; this one is a proposed change. Still, see above as it still applies
3) The possibility to select the backend to use in base of the entity Id used for authentication. Proof of concept here: https://github.com/IdentityPython/SATOSA/pull/220 <https://github.com/IdentityPython/SATOSA/pull/220>. I cannot do a separate microservice because this implementation needs a little but easy implementation into SATOSA core, I tried to code it as easy to read as possible.
This extends custom routing. Ivan will look at it.
2. Hackathon planning - https://wiki.refeds.org/pages/viewpage.action?pageId=44959235 <https://wiki.refeds.org/pages/viewpage.action?pageId=44959235>
Note that you have to register (even if you’re a speaker).
What do people need to get started? Suggest setting up a VM for Satosa so that people have a ready-made environment. Can set up a small image with everything ready and packed in, with no other setup. Will put it in the repository as an image. Will reuse this for other purposes (including future Hackathon). In the past, we’ve talked about having images that demonstrate different use cases; can use this for small demos.
Action item for Ivan; will try to have that this week
For the OIDC Federation table - they need to have read the specification and understood it. There will be at least three people at this table, including two Java programmers. When they have something running, will start doing interop testing; Roland will have entities available for them to talk to to test their code. The SimpleSAMLphp programmer will also be there, but he may be at another table. The developers will have their own environment with them on their laptops.
Need to ask for white boards.
Would be good if the EIDAS people would be there.
John suggests looking at using this https://github.com/sitya/samlidp <https://github.com/sitya/samlidp> as a fast sp/idp deployment; might not be the best fit.
Christos points out that they have an instance that might allow people to spawn SPs there. But if you want the developer the experience to deploy the IdP, then need to do more. Probably don’t need the IdP to do anything special; need to focus on developing the proxy and microservices.
Pepe: as SP I used this for my tests: https://github.com/peppelinux/Django-Identity/tree/master/djangosaml2_sp/dj… <https://github.com/peppelinux/Django-Identity/tree/master/djangosaml2_sp/dj…> and pysaml2 idp I used uniAuth ( https://github.com/UniversitaDellaCalabria/uniAuth <https://github.com/UniversitaDellaCalabria/uniAuth>)
If anyone else has more ideas on what they’d like to see during the Hackathon, please post to the list or send to Ivan
3. AOB
Next call: 3 September 2019. Will discuss status of Hackathon prep, OIDC libraries (if Roland is available), any pyFF updates (if Scott/Leif are available), and items from the mailing list.
