Folks,
I'm thinking it might be a good idea to have a dev meeting
soon to discuss progress and some of the recent development
efforts that have been very active recently.
Who would be interested in (and able to) come to Stockholm
for a (say) 2 day workshop sometime in the Oct-Nov-Dec
time frame (when Sweden really shines as a warm and sunny
place you really want to travel to) ?
Cheers Leif
Hi,
I just created 3 pull requests in the new microservices repository that
add functionality to the LDAP attribute store:
1) Ignore an SP if so configured so that no attempt to lookup attributes
in the LDAP will be attempted. This is useful in particular when a
COmanage SP is behind the proxy and you want to just pass through the
attributes asserted by the IdP (or perhaps manage them with other
microservices first but not look up the user in LDAP).
2) The refactoring of how attributes asserted by the IdP are processed
to find the "primary identifier" that is then used to lookup the user in
LDAP. This is a breaking change in configuration syntax that I mentioned
earlier.
3) The ability to redirect to a configured URL if no record is returned
from LDAP. This is useful if the user has not enrolled in a VO and you
want to forward to an enrollment page or the like.
Also, a "heads up" that I am beginning another enhancement.
I did the "easy thing" first with LDAP, so the code right now opens a
connection, binds, does the search(es), then unbinds for each trip
through the proxy. Doing so is not, of course, optimal from the
performance perspective.
So I am evolving the code so that connection pools will be set up, one
for each LDAP server, when the proxy starts up and during a trip through
the proxy an existing connection should be used. In my early testing
this decreased the amount of time spent at the proxy by a factor of 5,
but of course the network "distance" between the proxy and LDAP affects
that and I am testing with the proxy local and the LDAP server not
local, so I do not expect such a large gain in production, but it should
be noticeably faster for the user.
If you have any questions or concerns about the LDAP attribute store
please let me know.
Thanks,
Scott K
Hi,
I am wondering if a separate repository for SATOSA plugins and/or
microservices has been set up yet?
I have some updates for the LDAP attribute store microservice that I have been
waitint to push until it is moved to a different repository.
Should I continue to wait or just go ahead and push the changes (or more
precisley submit a pull request)?
Thanks,
Scott K
I find Satosa having problems with the metadata signature validation since yesterday. Signatures created by both pyff and shib/xmlsectool cause satosa_saml_metadata.py fail with
saml2.sigver.XmlsecError: data and digest do not match. I am not aware of any configuration changes that are related to the issue.
Did someone reload and check metadata recently, with or without system update or a new Docker image?
This leads me to another question. Is Satosa capable of reloading metadata without restart?
Best regards
Rainer
Hi,
(Apologies in advance for a long and detailed note. TL;DR I want to make a
breaking change but I think I am directly working with everyone using the
microservice.)
I would like to make a breaking change to the LDAP attribute store
microservice. Specifically I want to change the name and syntax for the
configuration option 'idp_identifier' (but not the functionality).
That configuration option is used to determine what value(s) is used for
the LDAP filter that is constructed to search for user records in LDAP.
Currently a simple configuration would be
idp_identifiers:
- eppn
ldap_identifier_attribute: uid
That configuration would take the value asserted by the IdP for eppn (the
SATOSA internal name for that attribute as it is "seen" by the
microservice) and use it to construct the filter value, eg. '
skoranda at uwm.edu', so that for example the LDAP filter would be
(uid=skoranda at uwm.edu)
More complicated configurations that include the ability to combine values
including NameID values asserted by the IdP are included in the example
configuration.
But there are two problems I have with the current configuration and its
syntax:
1) The value that is used to construct the LDAP filter may not be directly
coming (asserted by) an IdP. It may have been constructed using another
microservice(s) that runs prior to the LDAP attribute store. So I think
instead of
idp_identifier
I want to name the configuration option
ordered_identifier_candidates
2) The syntax as seen in the current example is poor. After a helpful
dialogue with Ivan I prefer this syntax, which I think better illustrates
what is going on (this would be a fairly complicated example):
ordered_identifier_candidates:
- attribute_names: [epuid]
- attribute_names: [eppn, name_id]
name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- attribute_names: [eppn, edupersontargetedid]
- attribute_names: [eppn]
- attribute_names: [name_id]
name_id_format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
add_scope: issuer_entityid
- attribute_names: [edupersontargetedid]
add_scope: issuer_entityid
The simple configuration from above would become
ordered_identifier_candidates:
- attribute_names: [eppn]
An intermediate example configuration would be
ordered_identifier_candidates:
- attribute_names: [eppn]
- attribute_names: [edupersontargetedid]
add_scope: issuer_entityid
Normally I would of course prefer not to make a breaking change, but I
think I am working with everyone using the microservice and can direcftly
help them transition and I think it is early enough in the evolution of the
microservice that some flux is expected/allowed.
Thoughts?
Thanks,
Scott K
Hi,
Given the satosa uptake and the user questions we start getting, should
we create a satosa-users list for deployers and administrators that want
to use satosa ?
//Ioannis
--
------------------------------------------------------------------
Ioannis Kakavas - ikakavas at grnet.gr
Identity and Security Engineer
GRNET Network Operations Centre
Greek Research & Technology Network - http://www.grnet.gr
7, Kifisias Av. 115 23 Athens, Greece
Office: +30 2107474255
PGP Fingerprint: A5AA FB5E 740A 603B FAB1 9920 D70F 0CD5 9DE3 C262
------------------------------------------------------------------
I have to convert the mail attribute from an IDP that stores it in uppercase (like JON.DOE at IMPORTANORG.GOV :-) to lowercase. Does someone have amicroservice to do this? If not, what would be the best place to start, e.g. copying the attribute filter?
- Rainer
Dear all,
Does the SATOSA front end support HTTP-POST bindings? It isn't clear
from the code or documentation whether a HTTP-POST binding is supported
by the front end---or if it is, how to configure it.
I want to integrate Tableau with our VO, but it's throwing the following
error:
HTTP Status 500 -
org.opensaml.saml2.metadata.provider.MetadataProviderException: User
specified binding is not supported by the Identity Provider using
profile urn:oasis:names:tc:SAML:2.0:profiles:SSO:browser
The IdP metadata for SATOSA includes a HTTP-Redirect binding:
<SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://satosa/Saml2/sso/redirect"/>
According to this support forum thread, the solution is to specify a
HTTP-POST binding:
https://community.tableau.com/thread/145569
Best wishes,
Matthew
--
"The lyf so short, the craft so longe to lerne."
> Does the SATOSA front end support HTTP-POST bindings?
I found official confirmation that Tableau does not support the HTTP-Redirect or HTTP-SOAP bindings, only HTTP-POST:
http://kb.tableau.com/articles/issue/error-user-specified-binding-is-not-su…
Tableau uses OpenSAML-Java, so I'm not sure why it has this limitation.
--
"The lyf so short, the craft so longe to lerne."
