- Satosa-dev - lists3.sunet.se

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."

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

6 years, 4 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.

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, 5 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, 5 months

3
2
0 0

Default value semantics

by ivan.kanak＠gmail.com

Hello all, Across the satosa codebase there are places where a default behaviour is needed. There are two ways we signify this: - Using the empty string as a dictionary key - Using the string "default" as a dictionary key (where other keys define behaviour/settings for specific entities.) I am not sure how the project ended up with two ways to signify a default set, but it is annoying. In terms of the chosen strings to represent the default set, "" seems to be a valid choice, as no entity (usually entityid) should be empty. "default" on the other hand, is more descriptive and self documenting, and hopefully nobody uses that to describe and entity (or as an entityid). In terms of handling this, there is currently a function under `src/satosa/util.py` namely `get_dict_defaults()` that favours "" over "default" – it fallbacks to "default" if "" is not set. While this is fine and works, it is not used across the codebase. I would like this to be resolved and have a single way to signify a default behaviour. What are your opinions? Do you think this should settle to a single way of representing a default set, even if that means that people using "" or "default" will have to migrate (this would be a breaking change for their configs)? Which is the most appropriate way to go? Cheers, PS: This discussion was triggered by skoranda's PR here: https://github.com/IdentityPython/satosa_microservices/pull/6/files#r148260… -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 6 months

3
2
0 0

setting the IdP Discovery Profile common domain cookie

by skoranda＠gmail.com

Hi, The Shibboleth IdP has the nice feature [1] that it can be configured to set the IdP Discovery Profile common domain cookie [2] after receiving a valid assertion from an IdP. It can be useful because only IdPs that a user has actually successfully used are recorded and then later revealed as choices to the user in a subsequent flow. I have a use case where it would be helpful if the SP side of SATOSA could do the same thing. I ran find . -type f -exec grep -l _saml_idp {} \; on the SATOSA source and it did not return anything, so I suspect this functionality is not currently supported by SATOSA. Would anybody object to adding it? It would of course be "off" by default and would only set the cookie (with configurable properties) when configured to do so. Thoughts? Thanks, Scott K P.S. I understand that new approaches to discovery that will likely come out of the RA21 effort will probably supplant this functionality, but as usual the use case I need to support needs this "right now"... [1] See idpHistory and idpHistoryProps at https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions [2] See section 4.3 of http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

6 years, 6 months

1
0
0 0

Announcement - project PM

by leifj＠sunet.se

Dear all, I am pleased to announce that Heather Flanagan [1] has been funded by the National Institute of Health's National Institute of Allergies and Infectious Diseases (NIH NIAID) to act as the project manager for the Identity Python project. This represents a major step for the project and will enable us to move forward more quickly and will also help us establish the Identity Python governance and organizational structure needed for long-term sustainability of the project. [1] https://www.linkedin.com/in/hlflanagan/ Cheers Leif

6 years, 6 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev