ComponentSpace

Forums



Users couldn't view the switch accounts options when they try to login.


Users couldn't view the switch accounts options when they try to...

Author
Message
KevinZheng1989
KevinZheng1989
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 5
Hi,

I will briefly descript my question's background information. Our application is hosted on our University's VM, we use ComponentSpace to send the SAML request, and it uses our University's Azure AD SSO to validate users(as an IDP). However, we need to let some researchers from outside of our university login into this web application. So we created their accounts in our Azure AD domain, but they have their own Azure AD environment and also have their own work/org accounts, some of them may use the remember me function and store their work/org accounts' credentials to the browsers' cookies.

They say when they tried the Azure SSO login process on our application. The Azure cloud login portal doesn’t allow them to enter their university account, it logs in with their own work/org accounts, the portal redirects to the password part and they don’t even have a chance to log in with our university's accounts.

we have turned on forced login settings on our service provider's end. And some of those users don't want to clear caches or use incognito mode, so we need to allow those clients to choose which accounts they want to use when they try to log in with our Azure SSO. Any idea about how to implement this? Is there any configuration need to be set on the service provider's side? And also how to do it on Azure Cloud(IDP) side?

ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
You don't have a lot of control at the SP other than setting the ForceAuthn flag which you have done.

If users have previously logged out from their Azure account, I'm surprised they're not prompted to select an account and enter their credentials next time SSO is attempted.

I suggest contacting Microsoft to see what they recommend.

Let me know what you find.

Thanks.

Regards
ComponentSpace Development
KevinZheng1989
KevinZheng1989
New Member
New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)New Member (3 reputation)

Group: Forum Members
Posts: 2, Visits: 5
ComponentSpace - 4/23/2023
You don't have a lot of control at the SP other than setting the ForceAuthn flag which you have done.

If users have previously logged out from their Azure account, I'm surprised they're not prompted to select an account and enter their credentials next time SSO is attempted.

I suggest contacting Microsoft to see what they recommend.

Let me know what you find.

Thanks.

Thanks
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
You're welcome.

Regards
ComponentSpace Development
rachelcxt
rachelcxt
New Member
New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)New Member (1 reputation)

Group: Forum Members
Posts: 1, Visits: 23
I am having a similar problem, only with PingOne as the ID provider (that's the one I'm currently testing with).  I'm using ForceAuthn and RequestedUserName as options.  ForceAuthn seems to do nothing and RequestedUserName only does something when no user is logged into PingOne.  We plan to use any number of ID providers as determined by our many customers once this feature is rolled out (and they can add them themselves without contacting us).  We can't reasonably contact every one of those ID providers as they come up for solutions.  

The problem is like this.  Instead of being redirected to a page where they can only enter their password like the forum user above, they are passed right through the whole PingOne side of things and never see a PingOne page.  PingOne reports back to us that the currently logged in user on their end is logged in, even if we're trying to log in someone else, and it's on us to make sure we don't accidentally log the wrong person in.  All we can do then is report an error to the user asking them to log out of PingOne before trying again.  This is workable but not ideal, and leadership would like a better solution.  Is there anything else we can do?  Any ideas on how to get around this?  Perhaps the previous forum user can share what they ended up doing?
ComponentSpace
ComponentSpace
ComponentSpace Development
ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)ComponentSpace Development (4.4K reputation)

Group: Administrators
Posts: 3.2K, Visits: 11K
Unfortunately, PingOne is ignoring the ForceAuthn flag in the SAML authn request and therefore isn't compliant with the SAML v2.0 specification.

The specification states: 

ForceAuthn [Optional]
A Boolean value. If "true", the identity provider MUST authenticate the presenter directly rather than rely on a previous security context. If a value is not provided, the default is "false".

I've tested with PingOne and have confirmed the ForceAuthn flag is set to true in the SAML authn request and PingOne is not prompting the user to login if there's an existing authentication session. The only ways to clear PingOne's authentication session are to perform a successful SAML logout or to close all instances of the browser.

The same is true for Azure AD.

Setting the ForceAuthn flag is the only control the service provider has over any existing authentication session at the identity provider.

The simplest solution is to ask the user to close all instances of the browser on logout from your application so any authentication sessions are cleared. I realize this isn't an ideal solution but it would almost be mandatory if devices are being shared.

Another option is to prompt the user for their login name prior to the call to InitiateSsoAsync. You can include this name as RequestedUserName. More importantly, when you call ReceiveSsoAsync you can check the returned user name against the original name the user entered. If they don't match you could ask the user to logout and try again. Once again, it's not an ideal solution.

I'm afraid there is no ideal solution here and it's unfortunate that Ping Identity, Microsoft and no doubt others don't comply with such a fundamentally important aspect of the SAML specification.

Regards
ComponentSpace Development
GO


Similar Topics


Execution: 0.000. 2 queries. Compression Enabled.
Login
Existing Account
Email Address:


Password:


Select a Forum....












Forums, Documentation & Knowledge Base - ComponentSpace


Search