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