December 2017 - Satosa-dev - lists3.sunet.se

by ivan.kanak＠gmail.com

Hey everyone, Now that satosa-microservices are split into their own repository we should set the process which acquires them back to the setup. There are many options here: - have each microservice be its own python package and selectively install it using pip - have the microservices repo be a package itself and use pip to install it - have microservices repo as a git module under satosa (not suggested) - have microservices as something completely external and fetch using http/git (as shown below). This could mean a lot of different things - ie, should microservices use code from satosa? if so, satosa is a dependency to microservices and as such this makes microservices a package with dependencies, etc. - (more options?) Skoranda mentioned that > If you need the LDAP Attribute Store microservice you must also install ldap3 using pip: This indicates that certain microservices have their own dependencies. Users cannot guess what dependencies are needed for a certain microservice. This information should be explicit and automatically resolved by the microservice installation process. This leads me to think to having each microservice as a separate (python) package, with its own dependencies and deployment process, is the way to go. This is not a simple decision to make. Let's have a discussion on how the dev-community think it is better to be solved. Cheers, PS: This discussion was triggered by skoranda's PR here: https://github.com/IdentityPython/SATOSA/pull/168#discussion_r149634137 -- Ivan c00kiemon5ter Kanakarakis >:3

6 years

4
6
0 0

pysaml2 pull request to support signed response or signed assertions

by skoranda＠gmail.com

Hi, Currently in pysaml2 for an SP one can configure want_response_signed to require that the authn response be signed and want_assertions_signed to require that the assertion(s) in the response be signed. There is no way, however, to configure the SP to consume a response and require that either the response is signed or the assertion(s) is (are) signed. I just submitted a pull request that adds the configuration directive want_assertions_or_response_signed The documentation is updated to read: Indicates that *either* the Authentication Response *or* the assertions contained within the response to this SP must be signed. Valid values are True or False. Default value is False. This configuration directive **does not** override ``want_response_signed`` or ``want_assertions_signed``. For example, if ``want_response_signed`` is True and the Authentication Response is not signed an exception will be thrown regardless of the value for this configuration directive. Thus to configure the SP to accept either a signed response or signed assertions set ``want_response_signed`` and ``want_assertions_signed`` both to False and this directive to True. Example:: "service": { "sp": { "want_response_signed": False, "want_assertions_signed": False, "want_assertions_or_response_signed": True } } Most of the logic is a refactoring of the _parse_response() method on the Entity class in entity.py. I think this is the "cleanest" way of adding this functionality without a major refactoring. The issue is that the signature checking and the parsing of the XML payload are tightly tied together and in a way that makes it difficult to get a representation of the payload or response and then apply requirements to it. For example, the only way to parse the response and determine if there is a signature is to require a signature and call the parsing method and see if it throws an exception or not. But if the signature wasn't really required then the parsing method has to be called again without the flag requiring a signature, otherwise the response is never fully parsed. I do think all of that logic needs to be refactored (sooner rather than later) but doing so is going to require some significant discussions on design (perhaps a topic for Vienna?). In the meantime this enhancement, while not particularly "elegant", allows an SP to be configured so that it can deal with IdPs in a federation where some IdPs only sign responses and some only sign assertions (I have an immediate use case for that now for a SATOSA proxy sitting in a well known federation). I tested all 8 combinations of configuration [1] for want_response_signed want_assertions_signed want_assertions_or_response_signed with all 4 combinations of an IdP sending signed/unsigned responses/assertions for a total of 32 tests and verified that SATOSA acted as expected (either consuming the response or throwing the appropriate error). I also verified that if you set all three of the configuration options to 'False' then you get a significant warning in the log output. Please let me know if you have any questions or concerns. Thanks, Scott K [1] Not all of the 8 configurations "make sense" given that the new option does not override the existing options. I verified that even in the "non-sensical" configuration the right things happen.

6 years, 4 months

1
0
0 0

pysaml2 pull request to support signature verification for MDQ

by skoranda＠gmail.com

Hi, (Apologies sending this to the satosa-dev list but I don't recall that there is a dedicated pysaml2-dev email list?) I submitted a pull request to pysaml2 that enables configuration of signature verification for responses from a MDQ server: https://github.com/rohe/pysaml2/pull/483 I formally clicked to ask Ioannis for a review but welcome feedback from anyone. The current code allows MDQ configuration like this: metadata: mdq: - http://mdq.ukfederation.org.uk/ There is no way to specify a certificate to use to verify the signature and there is no verification done. The version in the pull request would still support that configuration but would enable this configuration: metadata: mdq: - url: http://mdq.ukfederation.org.uk/ cert: /etc/satosa/ukfederation-mdq.pem That follows the same configuration pattern as for remote metadata (ie. an aggregate downloaded from a URL). I did both positive and negative tests with the UK MDQ server and the Incommon beta MDQ server. I also updated the config.rst metadata example to show the explicit configuration. Please let me know if you have any questions or concerns. Thanks, Scott K

6 years, 4 months

1
0
0 0

idpy developers call - 19 December 2017

by hlflanagan＠sphericalcowgroup.com

Hello all, It's not zoom, but it's enough to get us started for next week. Here is your BlueJeans invitation to join the idpy developers call next week on Tuesday, 19 December @ 6am PT | 9am ET | 3pm CET. DRAFT Agenda: 0. Agenda bash 1. Project governance (Leif, Heather) 2. Review GitHub (does it have all the projects it's supposed to?) - https://github.com/IdentityPython 3. TIIME planning (Rainer, Heather) 4. AOB Agenda is flexible, so please let me know if you have something you'd like added. -Heather

6 years, 4 months

3
8
0 0

Bi-weekly call schedule

by hlflanagan＠sphericalcowgroup.com

Hello all, The process of setting up a call fell off the radar, but hopefully the poll results for a decent time slot for a regular, biweekly call still works for most. The proposal is to have a a biweekly call starting Tuesday, December 5 @ 15:00 GMT+1. This will give us four calls (five if we really want to meet on January 2) between now and TIIME. DRAFT AGENDA (Please add your topics to the thread) * Introductions * Planning for the TIIME workshop (what do you want to get out of it?) * Project governance status * Current coding priorities Does anyone have a particular preference for video conference tools? We could use Google Hangouts, Skype, or someone could volunteer something (Lifecloud?)

6 years, 4 months

6
6
0 0

Bi-weekly call schedule

by ivan.kanak＠gmail.com

Hi all, I will not be available before 11/12 because I'm traveling. Other than that, I had troubles with Skype group chat too. On 30 Nov 2017 13:12, "Leif Johansson" <leifj at sunet.se> wrote: On 2017-11-30 14:45, Ioannis Kakavas wrote: > I prefer not to use Skype if possible. We have had very decent > experience with https://appear.in/ <https://appear.in/>for the amount > of people we foresee in these calls. > I have zoom zoom usually rocks _______________________________________________ Satosa-dev mailing list Satosa-dev at lists.sunet.se https://lists.sunet.se/listinfo/satosa-dev

6 years, 4 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev December 2017