2:07 p.m.
Hi,
I know it has been talked about as "doable", but has anybody already
deployed SATOSA with a response microservice that implements a "step-up"
flow to leverage a second factor (like Duo) when the authenticating IdP
does not assert that MFA was used?
If so, are you considering sharing it and/or contributing it to the code
base?
If not, but you are considering such an implementation/deployment, can
you indicate if you are interested in collaborating on the development
and testing?
Thanks,
Scott K
2:12 p.m.
Is your idea to kick it back to the home IdP with requested authnContext set to only MFA
or to implement step-up MFA at the proxy?
We'd be interested in the former...
-----Original Message-----
From: Satosa-dev <satosa-dev-bounces at lists.sunet.se> On Behalf Of Scott
Koranda
Sent: Tuesday, April 23, 2019 9:07 AM
To: satosa-dev at lists.sunet.se
Subject: [Satosa-dev] SATOSA and step-up with Duo or the like
Hi,
I know it has been talked about as "doable", but has anybody already
deployed SATOSA with a response microservice that implements a "step-up"
flow to leverage a second factor (like Duo) when the authenticating IdP does
not assert that MFA was used?
If so, are you considering sharing it and/or contributing it to the code base?
If not, but you are considering such an implementation/deployment, can you
indicate if you are interested in collaborating on the development and
testing?
Thanks,
Scott K
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
2:17 p.m.
We tried that approach once upon a time, couldn't get past licensing issues...
-----Original Message-----
From: Scott Koranda <skoranda at gmail.com>
Sent: Tuesday, April 23, 2019 9:17 AM
To: Paul Caskey <pcaskey at internet2.edu>
Cc: satosa-dev at lists.sunet.se
Subject: Re: [Satosa-dev] SATOSA and step-up with Duo or the like
Hi,
Is your idea to kick it back to the home IdP with
requested
authnContext set to only MFA or to implement step-up MFA at the proxy?
We'd be interested in the former...
For now, more the latter...
Thanks,
Scott 
2:40 p.m.
Hi Scott,
I know Christos and Ivan have been working on a backend module that is
able to engage with the OpenConext Stepup service
(https://openconext.org/stepup/). As far as I am aware this includes a
microservice which implements the business logic to decide when to call
for step-up. I am not 100% sure what current status is, so I hope
Christos/Ivan can pitch in.
Niels
On 23-04-19 16:07, Scott Koranda wrote:
Hi,
I know it has been talked about as "doable", but has anybody already
deployed SATOSA with a response microservice that implements a "step-up"
flow to leverage a second factor (like Duo) when the authenticating IdP
does not assert that MFA was used?
If so, are you considering sharing it and/or contributing it to the code
base?
If not, but you are considering such an implementation/deployment, can
you indicate if you are interested in collaborating on the development
and testing?
Thanks,
Scott K
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
--
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:07 p.m.
I think that this is a great idea,
probably there would the need to configure also a selective policy, decide
which IdP needs MFA or, if MFA will be activated by default for every IdP,
which of them will be considered out from this policy.
If the MFA is already available IdP side this could be frustrating, so I
think that it could be a good Idea to put it in the proxy with selectables
IdP
Il giorno mar 23 apr 2019 alle ore 16:07 Scott Koranda <skoranda at gmail.com>
ha scritto:
Hi,
I know it has been talked about as "doable", but has anybody already
deployed SATOSA with a response microservice that implements a "step-up"
flow to leverage a second factor (like Duo) when the authenticating IdP
does not assert that MFA was used?
If so, are you considering sharing it and/or contributing it to the code
base?
If not, but you are considering such an implementation/deployment, can
you indicate if you are interested in collaborating on the development
and testing?
Thanks,
Scott K
_______________________________________________
Satosa-dev mailing list
Satosa-dev at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-dev
--
____________________
Dott. Giuseppe De Marco
CENTRO ICT DI ATENEO
University of Calabria
87036 Rende (CS) - Italy
Phone: +39 0984 496945
e-mail: giuseppe.demarco at unical.it
8:38 a.m.
Hey all,
everyone is top-posting; I'll try to answer inline
On Tue, 23 Apr 2019 at 18:08, Giuseppe De Marco
<giuseppe.demarco at unical.it> wrote:
I think that this is a great idea,
probably there would the need to configure also a selective policy, decide which IdP
needs MFA or, if MFA will be activated by default for every IdP, which of them will be
considered out from this policy.
If the MFA is already available IdP side this could be frustrating, so I think that it
could be a good Idea to put it in the proxy with selectables IdP
The IdP (or another service) will release the LoA information, but it
is a service that requires a certain LoA. Below, I describe the way we
map services to LoAs.
Il giorno mar 23 apr 2019 alle ore 16:07 Scott Koranda
<skoranda at gmail.com> ha scritto:
>
> Hi,
>
> I know it has been talked about as "doable", but has anybody already
> deployed SATOSA with a response microservice that implements a "step-up"
> flow to leverage a second factor (like Duo) when the authenticating IdP
> does not assert that MFA was used?
>
Yes. With eduTEAMS we have a micro-service which implements a mini-SP
with the purpose of connecting to an external service that will do the
"step-up". As Niels pointed out, we do this with the OpenConext Stepup
service[0] and we can assert a higher LoA using either Tiqr[1] or a
hardware authentication device like yubikey.
The configuration allows you to specify a complete pysaml2-based SP
configuration (just like the saml2 backend sp_config part), the
signature algorithm to be used (which will be part of pysaml2
configuration soon), an attribute whose value will be used as the
NameID value and a structure that maps SP-entity-ids to a minimum
required LoA and a list of LoAs that should also be accepted (higher
level than the required one).
When an authn-response is received the authn-context-class-ref and the
requester are checked against that list and if needed the current
state is saved and a new flow starts towards the Stepup service. When
the latter flow authn-response is received the new
authn-context-class-ref it is checked against the required LoA and
either an error is returned, or the state is restored, the LoA is
updated and the initial flow continues.
> If so, are you considering sharing it and/or
contributing it to the code
> base?
>
Yes, it should be made public. I should talk to Christos and set up a
public repo for this as others have asked for it. Do remind me if I
don't send out a response soon.
[0]: https://openconext.org/stepup/
[1]: https://tiqr.org/documentation/
Cheers,
--
Ivan c00kiemon5ter Kanakarakis >:3
1851
days inactive
1852
days old
6 comments
5 participants
participants (5)
-
giuseppe.demarco＠unical.it -
ivan.kanak＠gmail.com -
niels.vandijk＠surfnet.nl -
pcaskey＠internet2.edu -
skoranda＠gmail.com