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."
Hi,
On 20 August 2017 at 00:26, Rainer Hoerbe <rainer at hoerbe.at> wrote:
> In my current saml2saml use case I need to rename an attribute (the IPD’s
> principalname to surname). The quickest way for seems to be to have a second
> internal_attribute.yml and initialize frontend and backend with different
> setting. However, there might be a more elegant way. Is there already a
> microservice available that would allow me to configure such a conversion?
>
SATOSA was build to make this scenario easy (SaToSa stands for SAML to
SAML proxy). The backends and frontends have separate configurations,
as seen on the example docs [0][1]. What you need is to specify the
attribute_profile configuration option for each, and configure the
mapping correctly in internal_attributes.yaml
Example backend configuration:
module: satosa.backends.saml2.SAMLBackend
name: Saml2
config:
attribute_profile: samlback
sp_config:
...
Example frontend configuration:
module: satosa.frontends.saml2.SAMLFrontend
name: Saml2IDP
config:
attribute_profile: samlfront
idp_config:
...
Example internal_attributes
attributes:
name:
samlfront: [principalname]
samlback: [surname]
[0]: https://github.com/SUNET/SATOSA/blob/master/example/plugins/backends/saml2_…
[1]: https://github.com/SUNET/SATOSA/blob/master/example/plugins/frontends/saml2…
> Cheers, Rainer
>
Cheers,
--
Ivan Kanakarakis
Hello everyone,
SATOSA at its current state offers an attribute mapping configuration.
Internally, the attribute mapping mechanism does exactly what it
states: it maps attribute values from one attribute name to another.
The current format is as follows (can also be seen here[0]):
attributes:
identifier:
saml: [eduPersonPrincipalName]
openid: [sub]
While this declarative configuration is very useful and is what makes
SATOSA stand out as a proxy, there are cases where for the mapping to
be valid we would need to process the attribute value. Semantically,
that means that rather than mapping what is needed is conversion.
An example use case would be the mapping of the openid 'sub'
identifier to the saml 'eduPersonPrincipalName' attribute. From the
respective specifications[1][2] we can see that the two attributes
have different structure and requirements. The 'sub' identifier is
part of a JSON Web Token and thus inherits all the rules for forming a
valid JWT, plus the requirement of
> [...] It MUST NOT exceed 255 ASCII characters in length. [...]
while, for the eduPersonPrincipalName attribute we read
> [...] It should be represented in the form "user at scope" [...]
In order to map the sub identifier to eduPersonPrincipalName and
conform to the specification, processing of the attribute value should
take place, transforming the sub identifier format to the "user at scope"
format.
We propose a simple, non-intrusive change to the current attribute
mapping configuration format that would allow us to hook into the
mapping mechanism and process the attribute value before mapping it.
Here is the proposed format for the attribute mapping configuration:
attributes:
identifier:
saml: [eduPersonPrincipalName]
openid: [sub]
processor:
module: python.module.that.inherits.from.AttributeProcessor
key1: value1
key2: value2
The proposed change adds a _special_ sub-dictionary named "processor"
under each internal attribute dictionary, that requires the 'module'
key to be present. The 'module' key is the python module path of our
custom module that is responsible to process the attribute value. The
custom module inherits from the AttributeProcessor module, that
defines the interface of the processing method and its invocation.
Extra keys like 'key1' and 'key2' can be set and are passed as
arguments to our module, acting as module specific configuration
options, allowing further configuration flexibility of the processor.
By default, the AttributeProcessor does nothing more than simply
mapping the attribute value, which is what currently happens and what
should happen if "processor" is not set.
The above described format allows us to stay compatible with the
current configuration format, while giving us the choice and
flexibility to further define the mapping behaviour by allowing us to
hook into the mapping mechanism and process the attribute value.
We are currently working on an implementation and we would appreciate
any feedback on the format, the AttributeProcessor interface, naming
of the newly introduced parts ('processor', 'AttributeProcessor',
etc), and your opinion on whether this could be part of the core of
SATOSA.
[0]: https://github.com/SUNET/SATOSA/blob/master/example/internal_attributes.yam…
[1]: https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes
[2]: http://macedir.org/specs/eduperson/#eduPersonPrincipalName
Thanks,
--
Ivan Kanakarakis
According to my notes, there was a proposal for a f2f Sept 27 - 29... is
this still the plan? (It's about two months out, so for US originating
travel the window will rapidly close in terms of getting funding and
logistics in place.)
Thanks,
-Benn-
Hi,
Is there a place yet for contributed microservices?
I ask because I have written a microservice I am calling
"PrimaryIdentifier" for the NIAID use case.
An example configuration might look like this:
module: primary_identifier.PrimaryIdentifier
name: PrimaryIdentifier
config:
idp_identifiers:
- epuid
-
- eppn
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
-
- eppn
- edupersontargetedid
- eppn
-
- name_id: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
- issuer
-
- edupersontargetedid
- issuer
clear_input_attributes: no
primary_identifier: uid
on_error: https://registration.scienceforum.sc/registry/collaboration_error/co_collab…
With this configuration the microservice will examine the attributes
asserted by a campus/organization IdP and look in the following order
for a value to use as the primary identifier:
1) eduPersonUniqueId
2) eduPersonPrincipalName and SAML2 persistent NameID, in case the IdP
is signaling it reassigns eduPersonPrincipalName
3) eduPersonPrincipalName and eduPersonTargetedId, in case the IdP is
signaling it reassigns eduPersonPrincipalName
4) eduPersonPrincipalName
5) SAML2 persistent NameID
6) eduPersonTargetedId
The special identifier 'issuer' signals that any value found is to be
"scoped" with the entityID of the IdP.
When it finds the first value it can use from that search order it then
asserts that value as 'uid' to the SP.
If no value is found after the configured search order then since
'on_error' is set it will redirect the browser to an "error" service to
handle that error.
Right now we are planning on using a custom COmanage Registry plugin to
"catch" the error and display instructions to the user.
I am wondering if any other project might have use for the microservice?
Any other thoughts?
Thanks,
Scott K
