- Satosa-dev - lists3.sunet.se

organization and contact_person in the SAML2 frontend/backend configs

by xenophon＠irtnog.org

Hey all, Do either of these configuration settings have any purpose? If these are hold-overs from when SATOSA used to generate its own metadata, can we safely remove them from the example configuration? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

8 years, 1 month

3
2
0 0

acr_mapping in the SAML frontend

by xenophon＠irtnog.org

Dear all, Am I correct in thinking that acr_mapping overrides the AuthnContextClassRef from the user's IdP? If so, why would someone do that? Is it for normalizing SAML AuthnContextClassRef and OIDC acr claims? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

8 years, 1 month

2
2
0 0

Updated pull request, was adding metadata store to context

by skoranda＠sphericalcowgroup.com

Hi, I updated my pull request about adding the metadata store the SAML2 backend uses to the context so that it is available to response microservices. With assistance from Ivan it is now a much more general solution so that it can be re-used. So for example the SAML2 backend code is now # Add the metadata store the backend is using to the context. context.decorate_context(Context.KEY_BACKEND_METADATA_STORE, self.sp.metadata) and in the microservice I now have # Get the metadata store the SP for the proxy is using. metadata_store = context.get_decoration(Context.KEY_BACKEND_METADATA_STORE) Thanks, Scott K

8 years, 1 month

2
1
0 0

Overriding want_response_signed on a per-IdP basis

by xenophon＠irtnog.org

Dear all, I have an IdP that isn't signing its response (or is signing improperly). I looked at the code for pysaml2 and found the want_response_signed setting. I need to temporarily override want_response_signed while I work with the IdP operator to fix this issue, but I'd prefer to limit it to just the broken IdP. Is that possible and if so, how? Best wishes, Matthew -- "The lyf so short, the craft so longe to lerne."

8 years, 2 months

5
7
0 0

Reminder: idpy developers call, 9 January 2018

by hlflanagan＠sphericalcowgroup.com

Hello all, A reminder that we have a call on the calendar for next week, using BlueJeans. A copy of the calendar entry with the BlueJeans connection info is attached. ----- Updated Agenda: 0. Agenda bash 1. Project introduction - Policy stuff: How do we communicate? Where should issues be reported? - The community: Who is using our projects? How we communicate with these entities? How can they get involved? What are their concerns? - The competition: We offer a product, but there are other tools that can satisfy one's requirements. What are we doing differently and why. 2. Project governance (Leif, Heather) 3. Project technical details - Project goals and roadmap(s) - Are there missing parts/additions we could incorporate/develop? 4. Review GitHub (does it have all the projects it's supposed to?) - https://github.com/IdentityPython 5. TIIME planning (Rainer, Heather) 6. Administrivia - call schedule and platform for 2018 - idpy-discuss vs satosa-dev lists 7. AOB

8 years, 2 months

1
0
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.

8 years, 3 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

8 years, 3 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

8 years, 3 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?)

8 years, 3 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

8 years, 3 months

3
2
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev