Ability to use multiple entityID in SAML backend

[guillomovitch]

This is a not a bug, but a feature request. Just tell me if that's not the correct channel.

We are using Satosa in order to build an OIDC<->SAML gateway between SAML IdP and OIDC RP, registered in our national federation. We would like the Satosa SAML backend to be able to use a different EntityID in its SAML Authn Request, in order to allow IdPs to issue a different SAML Auth Response, for each configured OIDC RP. Basically, this would turn the backend into a silent gateway, instead of an explicit SAML Service Provider of its own.

Code Version

Satosa 8.4

Expected Behavior

If OIDC frontend is called from client1, SAML backend should issue Authn Request with client1_entityID as issuer.
If OIDC frontend is called from client2, SAML backend should issue Authn Request with client2_entityID as issuer.
...

Current Behavior

If OIDC frontend is called from client1, SAML backend issue Authn Request with its own configuration-defined entityID.
If OIDC frontend is called from client2, SAML backend issue Authn Request with its own configuration-defined entityID.

[peter-]

AFAIU this is possible when configuring multiple backends (of module: satosa.backends.saml2.SAMLBackend) in Satosa. How you'd generate multiple such backend configs is then your own problem, though. 😏
I'd imagine one could template many such backends via Ansible or other configuration management tooling.

[vladimir-mencl-eresearch]

Hi,

We run SATOSA in exactly the way you describe as a SAML (SP) / OIDC (OP) bridge in Tuakiri, the New Zealand Access Federation.

While the bridge is registered into the federation with its "default" SAML identity, individual services may get a standalone SAML identity registered into the federation. Each such service then has its own SAML backend.

We use the satosa.micro_services.custom_routing.DecideBackendByRequester plugin to map such clients (by their client_id) to the corresponding SAML backend.

Happy to share more details - the short answer is, yes, this works.

Cheers,
Vlad

[guillomovitch]

Hello Vladimir, Hello Peter.

Thanks both of you for your answer. We have to find a balance between our current self-management registration process, and automated gateway reconfiguration, but that seems at least an achievable solution, without satosa modification. Does it scale correctly ? We currently have 1250 SAML services in our national federation, proxyfing a similar number of OIDC services would require 1250 different SAML backends...

[vladimir-mencl-eresearch]

Hi,

I'm now not sure I got you right. Our federation is primarily SAML and SATOSA is used only for services that require OpenID Connect - to proxy to the SAML IdPs.

We only have a small number of services connected to the bridge - and the registration are so far handled manually, with our automation tooling generating the SATOSA config.

I'm not sure how it would scale at > 1000 services. Each SAML backend loads its own copy of the federation metadata, which could at such scale become problematic. For that, MDQ could be an answer - to avoid having the full federation metadata loaded for that many instances.

[Yoroitchi]

Hi,

We're in a similar context. We're trying to offer the possibility to integrate OIDC services into a SAML distributed federation.

Based on what you wrote, I understand that you have one SATOSA SAML backend per OIDC service (previously registered).

Does each backend is registered in your federation ? In that case I understand that the IdPs exchange directly with the backend because each backend would expose it's own endpoint assertion_consumer_service.

Or do you have only the default bridge registered in your federation and somehow, SATOSA handles IdPs' SAML responses through one endpoint ?

[vladimir-mencl-eresearch]

Hi,

Services that have standalone SAML identity (their own dedicated SAML backend) are registered directly into the federation and each IdP communicates with the service-specific SAML backend directly.

Our tooling (Ansible) renders the SATOSA config (cdb.json, saml_backend.yaml, decide_backend_by_requester.yaml, ...) - and also registers the SAML backend into the federation.

The defaults backend is only used for services that do not have their own dedicated SAML backend and connect to the federation with the default SAML backend (generic OIDC bridge SP).

Hope this helps.

Cheers,
Vlad

[Yoroitchi]

Thank you so much for your quick replie, it does help.

Cheers,

[guillomovitch]

Using differents instance of SAML backend, altough perfectly working for a prototype, seems a bit excessive for our use case. We are considering changes in the SAML backend code, keeping current behaviour unchanged, while allowing additional flexibility in derived backend implementations. An example of such a change is available here:
Renater@20d2777

With this change integrated upstream in Satosa, anyone could easily implement its own MySAMLBackend, inheriting from SAMLBackend, and just overrinding get_own_entity_id() to return a context-dependent (when context is available, of course) entityID, constructed in any arbitrary way.

Altough absolutly untested, does this make sense at all ?

[vladimir-mencl-eresearch]

I so far do not see what would drive the overridden get_own_entity_id() to return different entityID - would there be per-client configuration?

It might work, though:

• it would mean the same certificate would be used for all "SAML entities". That might look confusing to some IdPs - and be rejected by AD.
• it would be hard (or not possible) to configure metadata loaded by the shared backend (e.g., local federation only vs also include eduGAIN).

That's my quick thoughts on it...

[guillomovitch]

Sorry for the late reply. Indeed, we expect to return a different entityID by client, based on context. The goal is to translate each OIDC RP as a SAML entity in metadata.

I don't expect any difficulty for sharing the same certificate between these entities: that's already the case for all our services, hosted behing a single shared shibboleth SP as reverse-proxy, and we don't have difficulties so far.

I don't understand your second point, tough.