Okta's MFA and Shibboleth

Lohr, Donald A - lohrda lohrda at jmu.edu
Tue Apr 4 16:50:09 UTC 2023


Just trying to get my head around it all by looking at all of the 
possible scenarios and integration points (as I understand things now - 
with limited knowledge) if we were to walk down any of these paths.

I think what I am after is not being asked for correctly and thus likely 
not being read correctly, because I still feel like I have unanswered 
questions.

Thanks,
Don

On 4/4/23 12:42 PM, Eric Goodman via users wrote:
> *CAUTION: *This email originated from outside of JMU. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> ------------------------------------------------------------------------
>
> No. The application asks Shibboleth to authenticate the user. 
> Shibboleth hands off the authentication to Okta. Okta sees the 
> application being “Shibboleth”. It doesn’t see the actual InCommon SP 
> the user is attempting to access. You could potentially (manually) add 
> applications in Okta that redirected the user to a URL that would 
> initiate a login to the InCommon SP, but nothing would happen 
> automatically.
>
> If you are setting up Shibboleth to authenticate users of InCommon SPs 
> against Okta via SAML, then you are by definition proxying. You can’t 
> discuss the situation without considering the proxying aspects.
>
> As to your other question (can Shibboleth use the Okta MFA product?):
>
> No, not directly (at least last I looked).
>
> Shibboleth relies on Okta MFA indirectly.
>
> I.e., if Okta is configured to require MFA for the “Shibboleth” 
> application, then every user authenticating to Shibboleth through Okta 
> will be challenged for MFA by Okta. In this case Shibboleth logins 
> “use” the Okta MFA.
>
> However, there is no way for Shibboleth to explicitly request that MFA 
> be done, to invoke the Okta MFA directly, or to inspect the result of 
> the MFA challenge by talking to Okta. The Shibboleth operator is just 
> relying on its knowledge of how Okta’s internal authentication is 
> configured. (If Okta is interacting with a third party MFA solution, 
> then Shibboleth could also be configured to talk to that, but I don’t 
> think that’s what you are asking here).
>
> --- Eric
>
> *From:* users <users-bounces at shibboleth.net> *On Behalf Of *Lohr, 
> Donald A - lohrda via users
> *Sent:* Tuesday, April 4, 2023 9:01 AM
> *To:* users at shibboleth.net
> *Cc:* Lohr, Donald A - lohrda <lohrda at jmu.edu>
> *Subject:* Re: Okta's MFA and Shibboleth
>
> *CAUTION: EXTERNAL EMAIL*
>
> Yes, I know what you mention about Okta and InCommon.
>
> For the sake of argument, let's say you were keeping 
> Shibboleth/InCommon and proxying with Shibboleth.
>
> Will all of the applications that exist in the InCommon metadata have 
> an icon in your Okta portal?
>
> Thanks,
> Don
>
> On 4/4/23 11:45 AM, Herron, Joel D wrote:
>
>     *CAUTION: *This email originated from outside of JMU. Do not click
>     links or open attachments unless you recognize the sender and know
>     the content is safe.
>
>     ------------------------------------------------------------------------
>
>     Yes, we are. We will be using a third party integration with Okta
>     to manage the two federations that we are part of. Until we
>     implement that solution we will keep inCommon in shibboleth. There
>     is no built-in way to manage a federation in Okta your either
>     keeping shibboleth and proxying or purchasing a third party
>     product to manage it for you.
>
>     --Joel
>
>     *From: *users <users-bounces at shibboleth.net>
>     <mailto:users-bounces at shibboleth.net> on behalf of Lohr, Donald A
>     - lohrda via users <users at shibboleth.net>
>     <mailto:users at shibboleth.net>
>     *Date: *Tuesday, April 4, 2023 at 10:33 AM
>     *To: *users at shibboleth.net <users at shibboleth.net>
>     <mailto:users at shibboleth.net>
>     *Cc: *Lohr, Donald A - lohrda <lohrda at jmu.edu> <mailto:lohrda at jmu.edu>
>     *Subject: *Re: Okta's MFA and Shibboleth
>
>     *EXTERNAL EMAIL*
>
>     Let's remove the proxying part of the conversation for a moment.
>
>     Are you an InCommon Federation member?
>
>     Thanks,
>     Don
>
>     On 4/4/23 11:28 AM, Herron, Joel D wrote:
>
>         *CAUTION: *This email originated from outside of JMU. Do not
>         click links or open attachments unless you recognize the
>         sender and know the content is safe.
>
>         ------------------------------------------------------------------------
>
>         Don,
>
>         We are in the process of setting up okta. I can tell you that
>         I have successfully proxied the IDP back to Okta and then you
>         can use whatever MFA method you want to inside of Okta. We are
>         still using Duo through Okta and it is working just fine. I
>         will also heavily agree with Scott  Okta’s SAML implementation
>         is trash.
>
>         All I had to do was follow the proxy to another IDP guide and
>         it was an easy setup.
>
>         Joel Herron
>
>         DevOps Engineer
>
>         ICIT
>
>         UW-Whitewater
>
>         *From: *users <users-bounces at shibboleth.net>
>         <mailto:users-bounces at shibboleth.net> on behalf of Lohr,
>         Donald A - lohrda via users <users at shibboleth.net>
>         <mailto:users at shibboleth.net>
>         *Date: *Tuesday, April 4, 2023 at 10:21 AM
>         *To: *Cantor, Scott <cantor.2 at osu.edu>
>         <mailto:cantor.2 at osu.edu>, Shib Users <users at shibboleth.net>
>         <mailto:users at shibboleth.net>
>         *Cc: *Lohr, Donald A - lohrda <lohrda at jmu.edu>
>         <mailto:lohrda at jmu.edu>
>         *Subject: *Re: Okta's MFA and Shibboleth
>
>         *EXTERNAL EMAIL*
>
>         Basically my question is: Can a Shibboleth IdP be configured
>         to use the Okta vendor's MFA product?
>
>         Thanks,
>         Don
>
>         On 4/4/23 11:00 AM, Cantor, Scott wrote:
>
>             CAUTION: This email originated from outside of JMU. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>             ________________________________
>
>               
>
>             What may be true however is that you may not have the ability to control which applications get MFA'd by Okta, given that they very likely do not support the actual proxying semantics of SAML or have the ability to consume the RequesterID element to influence behavior.
>
>               
>
>             So if you didn't mean all or nothing re: MFA, then you may be correct.
>
>               
>
>             -- Scott
>
>               
>
>               
>
>
>
>
>
>         -- 
>
>         D o n a l d   L o h r
>
>         I n f o r m a t i o n   S y s t e m s
>
>         J a m e s   M a d i s o n   U n i v e r s i t y
>
>         5 4 0 . 5 6 8 . 3 7 3 0
>
>
>
>
>
>
>
>     -- 
>
>     D o n a l d   L o h r
>
>     I n f o r m a t i o n   S y s t e m s
>
>     J a m e s   M a d i s o n   U n i v e r s i t y
>
>     5 4 0 . 5 6 8 . 3 7 3 0
>
>
>
>
>
> -- 
> D o n a l d   L o h r
> I n f o r m a t i o n   S y s t e m s
> J a m e s   M a d i s o n   U n i v e r s i t y
> 5 4 0 . 5 6 8 . 3 7 3 0
>

-- 
D o n a l d   L o h r
I n f o r m a t i o n   S y s t e m s
J a m e s   M a d i s o n   U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230404/3274d496/attachment.htm>


More information about the users mailing list