Home
The SamlToSaml (but also SamlToOIDC, OIDCToSaml etc) Proxy.
- Cloud/SaaS proxy - Proxy an SP to many SAML IDPs and provide interface to IDP-discovery
Frequently implementations of SAML libraries only support connections to a single IDP. SATOSA provides a highly interoperable interface to a multi-party federation. This allows for the efficient integration of an application with a basic SAML or OIDC connector.
- Collaboration Management: Manage federated identities with customizing options, policies and adding attributes
Certain collaborations bring users from different domains together, and require both their organizational login and the capability to locally add project-specific attributes and privileges. SATOSA can enhance the attributes received from a remote IDP with data from a local directory, providing an application with a rich attribute set that does not need to be managed per application.
- Make XXX-IDP compatible with federation (like ADFS, Siteminder, KeyCloak, ..)
Like the application/Service Provider/Relying Party side, many SAML IDPs have limited capabilities. In particular the support for dynamically configuring SPs using Metadata (SAML Meta-Interoperability specification) is spotty or cumbersome. Another, ADFS-specific limitation is the lack of support for interactive flows between authentication and assertion, e.g. for profile completion or consent. SATOSA can be grouped with such an IDP to provide high interoperability in scalable federations and allows the addition of custom user flows.
- Make a non-conformant SP SAML library SAML-compatible
Sometimes implementations are broken, incomplete or expect an IDP with certain restricted properties. Use SATOSA to shield this behavior from the outside world, without having to switch to other integration options that might require more effort.
- Protocol conversion
As older protocols are rarely replaced scenarios with a mix of SAML and OIDC will become more likely. SATOSA can mediate the SSO-flows between SAML and OIDC, or other protocols depending on the available frontend and backend plugins.
- "Social" ID proxy, transparent proxy
SATOSA can interface FB, Google etc. as IDPs, making the available as IDP in discovery lists, or as upstream IDP in the Cloud/SaaS proxy use case (see above).
- Policy enforcement (InAcademia)
A proxy can be used to enforce baseline policies across many SPs that sit behind the proxy. An example is InAcademia that does not reveal user attributes to the connect services/relying parties, except whether the user belongs to an academy.
- Single point of trust
The proxy can hide multiple SPs (or multiple IdPs). An IdP (or SP) by trusting one entity, is automatically connected to multiple SPs (or IdPs). Thus, the proxy acts for grouping federations together.
- Virtual IdPs for Collaborations
Extending the collaboration management use case, some collaborations want to expose an IdP interface to create a "vanity" IdP to represent their collaboration. The proxy can be used to implement multiple virtual IdPs that delegate authentication to campus and other organization IdPs that federate with the proxy backend, but that add project-specific attributes.
https://lists.sunet.se/listinfo/satosa-dev
TODO: document the development and release process