Dear Scott K.,
You mentioned last week something about accessing the metadata of the
IdP used to authenticate the user from within a microservice. This was
in the context of using information such as REFEDS R&S or SirTiFi
compliance to make access control decisions in SATOSA at time of
authentication. Would you mind elaborating?
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
Hi all,
I know this is not entirely the correct venue, but does anybody know
about an entity that would be able to provide a SaToSa training for
members of the AARC project?
Cheers,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
Hi all (and specifically Ivan as he was committing stuff),
I note a commit mentioning eIDAS integration, however what was committed
(https://github.com/IdentityPython/SATOSA/commit/a0b7cf9eb73714cef76d6ab7249…)
seems a bit too little to actually engage with eIDAS. I am for example
not seeing any reference to eIDAS specific saml extentions. Is all of
that covered in pySAML? I found this as well
(https://github.com/grnet/pysaml2eidas/tree/devel) , but that does not
seem to be used by SatoSa?
What would I need to pull together to setup a satosa based eIDAS gateway?
thanks,
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
Hi all,
I would like to mint a new attribute scheme called voPerson
(https://voperson.org/) for use in a SaToSa? What would be the best
approach?
thanks!
Niels
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nlwww.openconext.org
Hey everyone,
I am writing a SATOSA front end that implements SAML 2.0 IdP-initiated
(unsolicited) SSO. Currently, I plan to generate a SAML AuthnRequest
using a request variable (`providerID`) that names the service provider.
Eventually, I'd like to implement the same interface as Shibboleth
(request variables `shire`, `target`, and `time`) because I'm just not
that creative.
I have some (well, a lot of) questions:
- How do I get a list of SAMLFrontend endpoints?
- There could be more than one SAMLFrontend configured. How would I
know which one to use?
- I don't want to rely on JavaScript or the user to submit a form.
Can I send the AuthnRequest to the selected SAMLFrontend's HTTP-Redirect
endpoint via satosa.response.Redirect?
- Is it OK to omit the RelayState?
- In the SAML AuthnRequest, can I specify
AssertionConsumerServiceIndex="0"?
- If not, how do I look up the SP's AssertionConsumerServiceURL?
- In the SAML AuthnRequest, can I omit the Destination?
- If not, which endpoint should I set Destination to---HTTP-Redirect
or HTTP-POST?
- If I construct the redirect URL manually, do I base64-encode the
AuthnRequest using Python's base64.urlsafe_b64encode()?
- Should I use the urllib or requests library to construct the URL
instead?
Thanks in advance! :)
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
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
