- Idpy-discuss - lists3.sunet.se

Notes: idpy dev call, 3 March 2020

by hlflanagan＠sphericalcowgroup.com

Attendees: John P., Giuseppe, Hannah, Roland, Scott, Ivan, Alex, Johan, Christos, Heather Notes: 0 - Agenda bash 1 - Discussion a. <NameIDPolicy> and <NameID> Format attribute See discussions on slack. There is a policy setting; you may want to request a specific NameID format from an IdP, and if you don’t define the config option, what happens? We can request a NameID format in an authN request, and we can advertise in metadata what NameID we support. One thought (Ivan) is that it would be better not to advertise a NameID format, and only when you want a specific format to request it. Alternatively (Christos), do not request anything during the AuthN request, and to list in metadata in preference order the NameID format you will support. [Discussion] Should we leave this config option out, thus not setting the NameID policy at all? We should be able to set the NameID policy; there are use cases where we have to force this. Separating the two config options is a good thing to do. We need to set a NameID policy without a NameID. The string “none” is a hack. We can set some defaults, and if we need more complexity, it should probably be in a microservice. Christos points out that a microservice can’t do this because it’s at the wrong place in the workflow. The microservice architecture would need to be refactored. Satosa defines an internal representation fo the data, and the microservices act on that. When something is defined we need to make sure it can be defined into something for the outgoing protocol; for NameID, at the point the microservices are requested, they don’t have access to the backend or its metadata. We would need to make a change that would allow some or all microservices to run at a different point. If anyone has specific requirements here, please let Ivan know. b. Custom syntax in YAML - https://github.com/IdentityPython/SATOSA/pull/316 A new tag that would allow us to specify an environment variable. Use case: a deployment via docker swarm or kubernetes, and it is convenient to inject secrets via environment variables into the containers. Was handled via entry point scripts. The YAML config files are in an open Git repository. This gets cumbersome. Scott implemented a first draft, and Ivan improved it. Could we use py files instead of YAML files? This would work for pySAML2, but not for Satosa. Ivan will think about this a bit more, and then either merge the code or figure out another way to do this. Action item: Scott will improve the documentation (more examples would help) Action item: Ivan to consider this further; code is fine if we go with the current syntax. c. Shibboleth encryption algorithms Use case: the Shib project has announced that as of v4 of the IdP, default will be GCM encryption. This can be changed either globally or per RP. There are many Satosa SPs that will need to be able to consume that default. This is handled correctly for Satosa, but pySAML2 has two backends for encryption, and one uses xmlsec1, and the other on a python security library. With the xmlsec1, we generate the commands and run them from the xmlsec1 binary. Whether we can read/decrypt the GCM based payloads depends on what xmlsec1 supports. If your openSSL supports the GCM encryption, then xmlsec1 will support it as well, and everything should work correctly. We do need to add the different algorithms to pySAML2. Action item: Scott to open an issue against pySAML2 to help track this 2 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Will discuss at a future meeting (hopefully at the hackathon). Roland will release new versions tomorrow. b. Satosa - https://github.com/IdentityPython/SATOSA i. New release (v6.1.0) - https://github.com/IdentityPython/SATOSA/releases/tag/v6.1.0 Contains a new middleware dependency that takes care of the SameSite cookie issue. It sets the SameSite attribute to none. Note only Python 3.8 and newer are the only ones that know about the SameSite attribute. There is also a new dependency that takes that cookie, duplicates it, and removes the SameSite attribute; that means it sends two cookies, one with it set, one without. Clients that do not know what the SameSite attribute are about will drop it, and ones that do will have it. Satosa only cares about the cookie it sets itself. Deployer will need to define the configuration that takes the cookie name and the holdback name. See example: https://github.com/IdentityPython/SATOSA/blob/master/example/proxy_conf.yam… SameSite attribute is set here: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/state.py#L50 Monkey patch: https://github.com/IdentityPython/SATOSA/blob/master/src/satosa/cookies.py#… Release also includes a fix for sessionID. This comes out of some of the updates to logging. The sessionID is now part of the state, not part of where the logs happen. Now set pySAML2 to v5 or newer, in response to a security vulnerability that was patched in v5 c. pySAML2 - https://github.com/IdentityPython/pysaml2 d. pyFF - https://github.com/IdentityPython/pyFF 3 - AOB Thanks! Heather

4 years, 10 months

1
0
0 0

Reminder: idpy dev call, 3 March 2020

by hlflanagan＠sphericalcowgroup.com

BlueJeans: https://bluejeans.com/567481057 Agenda: 0 - Agenda bash 1 - Discussion a. <NameIDPolicy> and <NameID> Format attribute b. Custom syntax in YAML c. Shibboleth encryption algorithms 2 - GitHub review a. OIDC - https://github.com/IdentityPython (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) b. Satosa - https://github.com/IdentityPython/SATOSA i. New release (v6.1.0) c. pySAML2 - https://github.com/IdentityPython/pysaml2 d. pyFF - https://github.com/IdentityPython/pyFF 3 - AOB Thanks! Heather

4 years, 10 months

1
0
0 0

idpy dev call CANCELED for 18 February 2020

by hlflanagan＠sphericalcowgroup.com

Hi all, With so many people at the TIIME Workshop, we’re going to go ahead and cancel the call. A few topics have come up on the Slack channel that are likely of more general interest; Ivan will be posting to the list with more information on those. Talk to you all on our next call, currently scheduled for 3 March 2020! Thanks! Heather

4 years, 10 months

1
0
0 0

Notes: idpy dev call, 4 February 2020

by hlflanagan＠sphericalcowgroup.com

Attendees: Heather, Johan, Ivan, John P, Scott, Hannah, Giuseppe, Roland 0. Agenda bash Idpy.org <http://idpy.org/> domain issue - Leif is working on it Board continues as is, with Roland, Mike, Chris, and Ivan agreeing to serve for a new two-year term. Reminder: Hackathon/Workshop on March 23; please register! Ivan will be sending out information with more guidance on what work will be targeted that day. https://wiki.refeds.org/pages/viewpage.action?pageId=44959235 <https://wiki.refeds.org/pages/viewpage.action?pageId=44959235> The idpy BoF was rejected from TNC20. Space too limited. 1. GitHub review a. OIDC - https://github.com/IdentityPython <https://github.com/IdentityPython> (JWTConnect-Python-OidcRP, JWTConnect-Python-CryptoJWT, etc) Libraries are moved to the IdentityPython repository. Coding activity is in progress. There are some issues with Satosa in relation to the OIDC endpoint; GRNET is putting effort into fixing this. Roland is working on a few things in the libraries: pushed authentication, identity assurance (see https://bitbucket.org/openid/ekyc-ida/ <https://bitbucket.org/openid/ekyc-ida/> and https://bitbucket.org/openid/ekyc-ida/issues/1153/request-syntax-complexity <https://bitbucket.org/openid/ekyc-ida/issues/1153/request-syntax-complexity>), mutual TLS b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> Not a lot of progress since the last call. Have been discussing some of the common components between this and a new eduTEAMS project. There is a dependency between the proxy and services that live outside the proxy. Part of the discussion is how to define a common pattern/API on the info sent out to the services. May be encoding this information using SCIM (http://www.simplecloud.info/ <http://www.simplecloud.info/>). This would allow other services to get info from the proxy as well, since SCIM is a standardized model. Ivan will have more information on the wiki soon (and will send to the list) c. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> Signing encryption/decryption, and the names of identifier attributes: Ivan created a PR about this ( https://github.com/IdentityPython/pysaml2/pull/662 <https://github.com/IdentityPython/pysaml2/pull/662>). Would like for people to test that and see if it works for them. It is not following the specs closely, but it shouldn’t cause problems. Ivan will hold off merging it until there has been more testing. Will be merging: https://github.com/IdentityPython/pysaml2/pull/660 <https://github.com/IdentityPython/pysaml2/pull/660> https://github.com/IdentityPython/pysaml2/pull/645 <https://github.com/IdentityPython/pysaml2/pull/645> https://github.com/IdentityPython/pysaml2/pull/628 <https://github.com/IdentityPython/pysaml2/pull/628> https://github.com/IdentityPython/pysaml2/pull/625 <https://github.com/IdentityPython/pysaml2/pull/625> And then will have a new release. SameSite cookie handling - https://github.com/IdentityPython/pysaml2/pull/625 <https://github.com/IdentityPython/pysaml2/pull/625> See also discussion on Slack (https://identity-python.slack.com/archives/C4RR58T6C <https://identity-python.slack.com/archives/C4RR58T6C>) This will be part of the code; no other changes will be needed by deployers. Target release before end of February d. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> No update 2. AOB Next call scheduled for 18 February 2020

4 years, 11 months

1
0
0 0

Reminder: idpy dev call, 4 February 2020

by hlflanagan＠sphericalcowgroup.com

4 years, 11 months

1
0
0 0

Fwd: T&I Hackathon - 23 March 2020, Stockholm

by hlflanagan＠sphericalcowgroup.com

In case you’re not on the REFEDS mailing list... > Begin forwarded message: > > From: Heather Flanagan <hlf at sphericalcowconsulting.com> > Subject: T&I Hackathon - 23 March 2020, Stockholm > Date: January 29, 2020 at 12:48:01 PM GMT > To: refeds at lists.refeds.org > > Hola a todos! > > Are you attending the eduGAIN Town Hall on 24-25 March 2020? Are you interested in kicking off your week with some code development? Perhaps you have some questions on configuration, or ideas to improve documentation. You should join us, then, at the upcoming Trust & Identity Hackathon! > > Date: 23 March 2020 > Location: SUNET offices at Tulegatan (11 floor 3) in Stockholm > > Registration link: https://doodle.com/poll/p9apiwmnyzqq899w <https://doodle.com/poll/p9apiwmnyzqq899w> > > Wiki page: https://wiki.refeds.org/pages/viewpage.action?pageId=44959235 <https://wiki.refeds.org/pages/viewpage.action?pageId=44959235> > > Please register so we know how much coffee, tea, and sandwiches we need to acquire, and note in the registration notes what coding project you are interested in. We’ll organize tables as indicated in the registrations. > > Thanks, and I hope to see you in Stockholm! > > Heather

4 years, 11 months

1
0
0 0

Reminder: idpy dev call, 21 January 2020

by hlflanagan＠sphericalcowgroup.com

Meeting URL https://bluejeans.com/567481057 <https://bluejeans.com/252755948> Meeting ID 567 481 057 Agenda: 0. Agenda bash 1. Administrivia a. Idpy Board nominations 2. GitHub review a. OIDC - https://github.com/IdentityPython/oidcendpoint b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> c. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> d. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> 3. AOB

4 years, 11 months

1
0
0 0

Notes: idpy dev (off-week) call, 14 January 2020

by hlflanagan＠sphericalcowgroup.com

Attendees: Giuseppe, John P., Heather, Ivan, Roland, Scott, Hannah, Alex, Johan L, Christos Notes: 1. Administrivia a. idpy Board nominations

4 years, 12 months

2
1
0 0

PySaml2 v5.0.0 - Security release

by ivan.kanak＠gmail.com

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

4 years, 12 months

1
0
0 0

Reminder: idpy dev off-week call, 14 January 2020

by hlflanagan＠sphericalcowgroup.com

Meeting URL https://bluejeans.com/672796580 <https://bluejeans.com/252755948> Meeting ID 672 796 580 Agenda: 0. Agenda bash 1. Administrivia a. Idpy Board nominations b. March 23 Hackathon/Workshop in Stockholm 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…> b. Repository status 3. GitHub review a. OIDC implementations: b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> c. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> d. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> 4. AOB

4 years, 12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss