Hi-
After upgrading our Satosa to the latest, I am getting some deprecation warnings in the Satosa log.
I'll address the other 2 warnings later (I think they are related to python3), but for now I'm interested in how to use the new hasher microservice. I am not having much luck finding documentation for it.
The warning in the log is this:
"/usr/local/lib/python3.6/site-packages/satosa/base.py:56: DeprecationWarning: 'USER_ID_HASH_SALT' configuration option is deprecated. Use the hasher microservice instead."
Can you point me to some help in using that new microservice?
Thanks!
Hi all,
I would like to find out what the licenses of *all* components and
dependencies that make up SaToSa. Any suggestion to how to do that in an
automated fashion?
I could walk down the libraries manually in
virtualenv/lib/python3.5/site-packages, but that is rather tedious and
error prone. I also found some scripts to do this for me, however these
seem to just report what is in use at the os/system level, not
specifically for our virtualenv.
Any suggestions, or a solution you may have used previously?
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
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."
