Google Authenticator for CAS and Shibb IdPs
cantor.2 at osu.edu
Tue Feb 18 18:20:43 EST 2020
On 2/18/20, 5:36 PM, "users on behalf of IAM David Bantz" <users-bounces at shibboleth.net on behalf of dabantz at alaska.edu> wrote:
> Been asked by Management essentially
> "CAS appears able to use Authenticator for MFA SSO; why not Shibboleth?"
Because databases in the context of an IdP add complexity beyond the bounds of what most deployers want or will run, and we prioritize features on the basis of avoiding that dependency where we can. For this release, that means implementing SAML proxying ahead of working on native MFA solutions.
Duo was too dominant for the last few years to seriously consider competing with them, honestly.
> Independently, CISO hopes to require MFA for administrative access to Banner ERP, and hopes to do it without licensing
> Duo (purely cost consideration).
That means operating a bulletproof device registration and management portal and database, and that's a very big project, and is outside our normal scope. Duo costs what it does because of that, not because of push or a mobile app.
Secondarily, it isn't my opinion that OTP code style solutions have a serious chance of attracting support at most sites, it's a pain in the butt to use as a user. If we're going to spend a lot of time, it needs to include at least WebAuthn also, which further expands the scope of the work needed, but that's also code we have access to from Duke as well.
> any updates on possible Authenticator/Shibboleth integration
I still don't think a real management portal is in the picture, not without a different skill set. We are not web developers, not in the modern sense. We wouldn't produce anything a large campus would likely deploy, leaving a big gap. I would like to see somebody fill it, but there's nobody to do that right now.
Since there are no standard APIs for this, we would have to define a proprietary interface to the token store, but that part seems to be heading in the direction of using the attribute resolver, as discussed in that issue. That provides a good direction that should minimize the coupling needed and allows a pretty general way of interfacing to the token store.
More information about the users