12:28 p.m.
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
8:03 a.m.
New subject: Fwd: SaToSa for SP 1:n mapping and profile update workflow
Hi,
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.)
That should be straightforward (of course) with SATOSA.
(2) For some IDPs: Create/update an LDAP user object
for a subset of
attributes
You should find it straightforward to write a "microservice" that does
this.
There are a number of microservices already that you can look at for
guidance, but in particular the "LDAP attribute store" microservice will
already have code you can copy for connecting to an LDAP directory.
(3) Add a profile completion flow for first-time users
to
confirm/modify email addresses
The account linking and consent microservices can guide you. Note that
for both of those the flow actually leaves SATOSA and then comes back
(ie. the actual work is delegated to another service).
(4) Allow embedded discovery (SHOULD)
I am not sure what you mean by "embedded".
The SAML backend that interfaces with IdPs requires a discovery service
if there is metadata for more than one IdP. Normally you would just
configure that backend with the URL for an existing SAML discovery service.
If you really want SATOSA to "embed" the discovery service you could
write it as another frontend/backend (just inherit from the base classes
as the existing SAML frontend/backend do) with its own URL space.
(5) Staying compatible with the SaToSa upstream
project.
My experience so far is that the architecture of SATOSA makes it
straightforward to extend/customize without losing compatibility with
the upstream project.
The attached picture shows the options with 1:1 and
1:n mapping of
IDPs. Are both approaches supported by SaToSa?
I have not done it myself (I am focusing on more of a "full mesh"
architecture), but based on my understand of the SATOSA architecture I
would answer "yes", though probably not "out of the box" with just
configuration since you are attempting to do both at the same time.
I expect you will need to do some coding, but it will be
relatively straightforward.
Is it possible to add
an interactive flow to the proxy to update profile data?
Again, yes, see the account linking or consent microservices for
examples. They are "external" to SATOSA proper, but I expect that model
will work better for you in the long run.
My $0.02,
Scott K
8:10 a.m.
New subject: Fwd: SaToSa for SP 1:n mapping and profile update workflow
We have been testing successfully with pyFF for this, and next to that
also use pyff as our mdq. not dealing with metadata files makes satosa
significantly faster.
cheers,
Niels
On 31-05-17 10:03, Scott Koranda wrote:
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
(4) Allow
embedded discovery (SHOULD)
I am not sure what you mean by "embedded".
The SAML backend that interfaces with IdPs requires a discovery service
if there is metadata for more than one IdP. Normally you would just
configure that backend with the URL for an existing SAML discovery service.
If you really want SATOSA to "embed" the discovery service you could
write it as another frontend/backend (just inherit from the base classes
as the existing SAML frontend/backend do) with its own URL space.
8:25 a.m.
New subject: Fwd: SaToSa for SP 1:n mapping and profile update workflow
On 2017-05-31 10:10, Niels van Dijk wrote:
We have been testing successfully with pyFF for this,
and next to that
also use pyff as our mdq. not dealing with metadata files makes satosa
significantly faster.
Yeah there an open issue (which I plan to fix) around the use of mdq in
satosa depending on which "side is front" in your deployment but in the
standard s2s case like inacademia it works great.
2544
days inactive
2545
days old
3 comments
4 participants
participants (4)
-
leifj＠sunet.se -
niels.vandijk＠surfnet.nl -
rainer＠hoerbe.at -
skoranda＠gmail.com