February 2018 - 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

Default internal attributes?

by xenophon＠irtnog.org

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

6 years, 2 months

2
4
0 0

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

6 years, 2 months

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

6 years, 2 months

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

6 years, 2 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev February 2018