I recently completed an OpenId Connect integration of OneLogin to our asp.net core webapp.
I implemented the "authentication flow" and used the OneLogin OIDC .net sample app as a basis: https://github.com/onelogin/openid-connect-dotnet-core-sample
In our development and staging environments the OIDC integration works as expected, but in our production environment we see an oddity:
Once the user has completed their login and MFA challenge (we use Duo for the MFA challenge) the user is redirected back to perform their MFA challenge for a second time. After they've been through the MFA challenge for a second time, the flow redirects back to our app as expected.
Analysing the http requests it's clear that this looping back to the beginning of the MFA challenge is happening prior to the .net core "signin-oidc" callback in our web app. It all appears to be on the OneLogin side of things.
Specifically, after the MFA challenge hass succeeded a request is made like so:
GET https://ourdomain.onelogin.com/trust/openid-connect/v2?client_id=etc
The result of the request is a redirect back to the start of the MFA challenge i.e.
https://ourdomain.onelogin.com/login2/?return=
I'd expect the user to only have to complete the MFA challenge once, instead of the twice that we're seeing.
I'm struggling to diagnose the issue as it doesn't appear to be related to my code. Any ideas?
After going through OneLogin support this turned out to be a bug on their side. A workaround was to change the configuration option which controls how often to show the MFA. (It was previously set to always show the MFA challenge)
Related
I have an application that I need to do the authentication to an IDP (Azure) and if the authentication fails I want that the IDP to send back a response to my application that user is not authorise .the issue is that IDPs are not sending any information regarding the authentication failed and is just remaining on login screen.
Any ideas?
Best regards,
Mircea
Regardless of the SSO protocol used, Azure AD will always return an error code, message and debugging information.
If that's not the case, then Collect a network trace with Fiddler and post the results here minus any confidential information for additional debugging.
Optionally, you may try to Test SAML-based single sign-on from the Azure Portal to verify your application correct configuration.
Most likely it is an issue with the Redirect URI being used in the application for the event when user is not found on the IDP (Azure AD). This seems to quite similar to the following issue: Redirect not working for SAML login, php-saml with Azure Active Directory
I am currently developing an SPA application that connects to a bunch of webAPI's. These API require that the user is logged in, so I started digging into Openid Conect and OAuth2 examples, mostly using IdentityServer.
They all require, for SPA reasons, that the implicit grant should be used for retrieving access_tokens. Token refreshes are handled connecting to authentication server using hidden iframe.
What I understand from this approach o renewing your access_token is that, sessions is maintained at authentication service. Hidden iframe goes to the authentication server, sessions is still active, new access_token is provided.
All that looks good for me, except (for UX reasosn) the fact that my user needs to be redirected to authentication server page for providing credentials.
Isn't it possible to have my SPA application send credentials to authentication server, getting the access_token, and then do the refresh using the hidden iframe for silently renewing (we, obviously dont want the user to keep informing credentials every 15 minutes or every hour..).
If this is not acceptable for security reasons, could you please explain why?
Technically it is possible with "resource owner password flow", but in that model identity provider can not trust your application and will not create a session for your user (to use silent renew later on). Thus such non-interactive approach is not truly SSO. For 2019 the recommended flow for any web app such as Angular SPA is Code flow with PKCE extension, as described here or there.
EDIT:
Editing this answer to correctly reflect the requirement.
If the requirement is not to show authentication server page and use your own SPA, the only possible way to do it is using "Resource owner password flow" with the constraints mentioned in the previous answer
This is discouraged for two reasons:
Security - Will the SPA have the same security controls as the "Authentication server" has in handling passwords of the user. Right from collection to management of the user password (safely securing for future calls ?). This will massively impact the scope of SPA and it is one of the main reasons why people prefer federated logins (outsourcing login complexity to the third party - in your case authentications server)
Trust - How would you convince the user to handout the "authentication server" password to a relatively new SPA app. Imagine if Google / Facebook allows this pattern for a SPA to collect password instead of redirecting to the Google / Facebook login page. This is a recipe for disaster.
This is exactly what oidc-client-js library does. Have a look at automaticSilentRenew settings in their wiki page. Understandably this only works as long as the session at the authentication server is still active.
Good Evening,
My group is rolling out SSO - yay. We have several applications that directly authenticate with Box.com and all token refreshes are handled automatically. After we migrated to SSO, we didn't include these service (app) accounts in our AD, so they do not have access via the SSO gateway.
My (likely incorrect) understanding of how OAuth with an SSO provider in the loop works:
We can still start the OAuth handshake directly with box - but box will forward this request to the SSO provider. The SSO provider will then authenticate the credentials and pass back a "all good" to box, which will issue an auth_token.
This is based off of the following from box:
"If you authenticate your application via Box’s OAuth 2.0, your
application will automatically let the customer sign-on with their
company credentials, just like they do with every other Box
application. This also applies to popular commercial services like
Okta, One Login, and Ping."
https://docs.box.com/docs/oauth-20
As well as this photo:
So if the external applications' service accounts with Box aren't in the AD of the SSO (too many acronyms), they should not be able to authenticate right?
But these apps are continuing to be able to authenticate. They are able to refresh their token and continue accessing box, even after the migration to SSO.
Where is the flaw in my understanding? Will these apps need to be added to the AD, or does this roll out of SSO not affect any of our external dependencies?
Thanks!
Got an answer from box:
third-party apps and integrations use a persistent authentication
token model. This means that unless a user deliberately logs them out
of the app, or an admin inactivates or deletes their account, this
user will never have to re-authenticate after initial login. Instead,
the app/integration will refresh their tokens. Refreshing tokens does
not require stepping through the SSO login flow, while generating an
initial set of tokens does.
Changes in SSO status, whether between SSO Off, Enabled, and Required,
or between two different connections, have no effect on existing
authentication sessions. Users won't be forcibly logged out when SSO
is turned on.
Upon next login attempt will the new SSO flow come into play. In this case, these users were already authenticated into the integration
prior to SSO roll-out. The SSO change would have impacted behavior in
that these users would need to authenticate via SSO going forward;
however, due to the persistent authentication model, that "next login"
never actually happens, and these users can continue to refresh tokens
and retain access without ever being challenged to authenticate into
the IdP again.
Our organization uses single sign-on functionality to log into Rally automatically for each user. Wit custom apps I have created in the past which use the Web Services API, this doesn't appear to cause any troubles, however, when a user who has SSO enabled tries to run an app which uses the Lookback API, a login box appears (shown below). Neither the user's SSO credentials or their previous Rally login credentials seem to work in gaining them access to the API.
My assumption that it is SSO causing this problem is strictly based on the fact that the few of us with it disabled do not run into these problems, however those using SSO encounter it every time.
Has anyone experienced this issue before?
Jake's team at Rally deployed an update that should have resolved this issue. Don't hesitate to post back if it's still occurring or if there's other concerns.
My team is getting started with Desire2Learn Valence, and our Shibboleth authentication seems to be derailing the initial API Key authentication process.
We have our App ID and Key, but the Valence authentication form is sending us to our Shib login (not our direct login, as it does for the "Lake Valley University" sample) and it never makes it back to Valence to complete the process.
Any suggestions on how to configure or change this so it works?
Valence authentication is based on deep-linking (ultimately the Valence Authentication page directs the user back to the app with some key information attached).
Therefore, the LMS' authentication system has to be configured for deep-linking, which occasionally is not true for some systems. Also there are particular versions of the shibboleth authentication system required to support that deep-linking.
The Valence authentication process flow follows the links the deployment team (or site administrator) provides in the DOME for Tools.Login.OrgLoginPath and Tools.Login.OrgMobileLoginPath. This will be why you are going to the Shib page instead of the built-in page. Some Shibboleth customers create a portal page to give users a prompt and choice of which system to authenticate against. All the pages in the process have to pass along the deep-linking url as the ?target= query parameter.
As it is not returning to the app this suggests it needs an updated version of the Shib product (IPAS). I would open a help desk ticket for this item and refer to the fact that you are doing this for using it with Desire2Learn Valence authentication.