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
Hey everyone,
In the example config, there's this list of internal attributes:
https://raw.githubusercontent.com/IdentityPython/SATOSA/master/example/i
nternal_attributes.yaml.example
How does that relate to the attribute maps defined in the Docker
container?
https://github.com/IdentityPython/SATOSA/tree/master/docker/attributemap
s
Those appear to be the same as the ones defined in pysaml2 (with the
exception of several EIDAS attribute mappings missing from SATOSA's
version):
https://github.com/rohe/pysaml2/tree/master/src/saml2/attributemaps
What's the Right Way to configure or extend the attribute mappings?
Can I assume the ones from pysaml2 are already loaded?
Also, where do I find the attribute mappings for other protocols, like
OIDC? I looked at the pyoidc sources, but I didn't find similar data
structures or source code.
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
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."
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
