Hi,
I just pushed pysaml2 PR #613 to enable more flexible entity catetory
support:
https://github.com/IdentityPython/pysaml2/pull/613
Before this PR entity category modules to be used to help configure
attribute release for an IdP could only be imported from
the name space saml2.entity_category. This is cumbersome and made
overlaying new entity category modules or custom versions of existing
entity category modules difficult.
With this PR entity category modules are first searched for on the
general module import path. If they are not found there then the current
default of importing from saml2.entity_category.<module> is used.
Thanks,
Scott K
In my effort to clean up pyff (cf recent posts) I have created an
HTML5/JS frontend app that closely mirrors the "admin" application
that pyffd currently comes with: https://github.com/SUNET/mdq-browser
This is another step in the (previously announced) plan to make
core pyFF less of a monolith.
Also the api-refactory has seen a lot of work recently, notably
adding several APIs to help instrument pyFF and a rewrite of the
fetch module to use apscheduler which looks like a great tool for
managing asynchronous operations.
Cheers Leif
Hola a todos!
After much discussion, debate, and research, the Identity Python board (https://idpy.org/organization/) has agreed upon a Note Well [1] to govern contributions to all Identity Python Projects. This Note Well is linked off the Contribute page on our website. See https://idpy.org/contribute/.
Please let me know if you have any questions!
-Heather
[1] Full text:
Identity Python Note Well
version 1 - Approved 1 May 2019 by the Identity Python Board
This is a reminder of Identity Python policies in effect on various topics such as patents or other IPR.
• By participating (e.g., submitting code, attending in conference calls or meetings, posting to project mailing lists) in Identity Python projects, you agree to follow Identity Python processes and policies as defined in the Identity Python governance pages and in the GitHub Terms of Service.
• If you are aware of any code, component or material idea within any of the projects included in Identity Python that is covered by patents or patent applications that are owned or controlled by you, your sponsor, employer or any other organization with which you are affiliated, you have an obligation to disclose that fact, or refrain from contributing to Identity Python.
• By making a contribution to Identity Python you are asserting that you have permission to make such contributions on behalf of your sponsor employer or affiliated organization.
• If you are working on any code component jointly managed with another organization, you agree to abide by that organizations IPR policies and any requirements for a Contributor License Agreement.
• As a participant or attendee, you agree to work respectfully with other participants; please contact the Identity Python board board at idpy.org if you have any questions or concerns.
Hi,
Right now the saml2.py in src/satosa/backends/ has
def disco_query(self):
"""
Makes a request to the discovery server
:type context: satosa.context.Context
:type internal_req: satosa.internal.InternalData
:rtype: satosa.response.SeeOther
:param context: The current context
:param internal_req: The request
:return: Response
"""
return_url = self.sp.config.getattr("endpoints", "sp")["discovery_response"][0][0]
loc = self.sp.create_discovery_service_request(self.discosrv, self.sp.config.entityid, **{"return": return_url})
return SeeOther(loc)
Essentially this restricts the flow to one and only one IdP discovery
service that is configured statically.
I propose that this method be enhanced so that it can inspect the context
and internal data and if it finds a URL for the discovery service to use
it overrides what is in the configuration.
Then one can configure a request microservice that uses some logic to set
the URL for the discovery service, such as which SP the authentication
request came from.
Since the comment for the method already includes a mention of the context
and internal data, I suspect this functionality was designed but never
implemented.
Any objections to me implementing it?
Any other comments or input?
Thanks,
Scott K
Hola a todos!
Ivan and other members of the eduTEAMS team are unavailable this week, so we’ll go ahead and cancel the call. Our next meeting is scheduled for 30 April 2019.
Talk to you then!
Heather
Attending:
Johan, Heather, Ivan, Rainer
Project updates
Not much on the public repos. There has been quite a bit of work on eduTEAMS, which has a lot to do with microservices and how they use Satosa. Also has impact on the OIDC libraries.
Did do a fix for an issue Scott had with regards to how XMLsec errors were handled. First fix sent the code into an endless loop (oops) but latest patches should be fine. This patch will generate a new release, based on the new way we have agreed to generate releases.
Release process
We will cut a new release and it will be tagged with a branch. Community maintainers will work in the branch space, and core developers will work on the master branch. Latest release for pySAML is 4.6.5. Ivan will cut a new release (4.6.6) and then that branch will be incremented by the community maintainers (4.6.6.1 for first change).
Alternatively, Ivan could cut a 4.7 release, and community maintainers would maintain the minor release numbers only. This seems to make more sense; Ivan will do this.
Description of the release process text is copied in each repo. Heather to update it and pull that back into one location so that we only have to change it in one place.
Next on the list for Ivan: Satosa and pySAML2
Fixing redirect binding and some options set in Satosa but which are configured in pySAML2 (how we handle sign_assertion, sign_response, sign_alg, digest_alg). This is the same issue we’ve been talking to Martin about; this impacts eduTEAMS, SURF, and others.
Ivan will cut another release later this week with the fixes for above included. (This will be edition to the release today that fixes xmlsec)
Another issue: https://github.com/IdentityPython/pysaml2/issues/592 <https://github.com/IdentityPython/pysaml2/issues/592> do not properly check the certificate as a result of some of the configuration options. Will be changing the default values to require this checking; that may break some existing implementations. Ivan will be investigating further. This more a misconfiguration than a security issue.
Reminder: we’ll have another call in a week; Daylight Saving Time skew will still be a problem so check your calendars!
Hola a todos!
Since we had to cancel the call this week, let’s aim for a call this coming Tuesday. Please note that we’re entering in that time where Daylight Saving Time varies between much of the US and Europe, so this may not be at quite the usual time for all participants!
idpy Developers call (off week)
Scheduled: Mar 12, 2019 at 6:00 AM to 7:00 AM
To join the Meeting:
https://bluejeans.com/679462931
To join via Room System:
Video Conferencing System: bjn.vc -or-199.48.152.152
Meeting ID : 679462931
To join via phone :
1) Dial:
+1.408.740.7256 (US (San Jose))
+1.888.240.2560 (US Toll Free)
+1.408.317.9253 (US (Primary, San Jose))
(see all numbers - http://bluejeans.com/numbers)
2) Enter Conference ID : 679462931
