- Satosa-dev - lists3.sunet.se

by rainer＠hoerbe.at

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

6 years, 8 months

3
2
0 0

usage questions?

by liamr＠umich.edu

I apologize for contacting the dev list about this. Is there an appropriate group to contact about usage questions? Liam

6 years, 8 months

4
12
0 0

Front end support for the HTTP-POST binding

by xenophon＠irtnog.org

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

6 years, 8 months

3
5
0 0

Front end support for the HTTP-POST binding

by xenophon＠irtnog.org

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

6 years, 8 months

1
0
0 0

Attribute rename [Was: Re: Proposal: callback on attribute mapping]

by ivan＠grnet.gr

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

6 years, 9 months

2
1
0 0

Proposal: callback on attribute mapping

by ivan＠grnet.gr

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

6 years, 9 months

6
8
0 0

September f2f?

by benno＠sphericalcowgroup.com

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-

6 years, 9 months

1
0
0 0

microservice for primary identifier

by skoranda＠gmail.com

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

6 years, 10 months

4
6
0 0

Satosa governance meeting at TNC?

by hlflanagan＠gmail.com

Hi all, How appropriate that we are back in Austria, which is where we last had serious conversations about Satosa governance! Because we had a few actions out of that earlier meeting that we need to follow up on. Governance questions for Satosa: * IPR needs to be sorted out (who will hold it?) * CLAs need to be in place * Re-license if required Since many of the folks from the last meeting are here, how about finding a few minutes to meet on the above? Prioritization to the IPR question (since it is top of the list, and the other things fall from it). What time(s) do people have available tomorrow (Wednesday)? -Heather Sent from my iPad Sent from my iPad

6 years, 11 months

8
11
0 0

Fwd: SaToSa for SP 1:n mapping and profile update workflow

by rainer＠hoerbe.at

I need to build a SAML2SAML proxy and would like to adopt SaToSa for this project, which happens to be the Austrian K12 federation. With most IDPs a NREN-like mesh federation would be a straightforward solution, but there are a few requirements that need a proxy: (1) The IDP for federal employees needs to see all K12 applications appear as a single SP. (The use case is commercial, because the IDP is charging per application and per user.) (2) For some IDPs: Create/update an LDAP user object for a subset of attributes (3) Add a profile completion flow for first-time users to confirm/modify email addresses (4) Allow embedded discovery (SHOULD) (5) Staying compatible with the SaToSa upstream project. The attached picture shows the options with 1:1 and 1:n mapping of IDPs. Are both approaches supported by SaToSa? Is it possible to add an interactive flow to the proxy to update profile data? - Rainer

6 years, 11 months

4
3
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Satosa-dev