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.
Related
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)
I'm using keycloak to let my users authenticate with my application. And i am trying to migrate some functionality to a few plugins, e.g. a wordpress plugin. For these plugins i want to use a generic solution so I found the following authentication process from Microsoft (https://learn.microsoft.com/en-us/office/dev/add-ins/develop/auth-external-add-ins#middleman-services) and Adobe ( https://adobexdplatform.com/plugin-docs/tutorials/how-to-integrate-with-OAuth/).
I managed to hack my way around the process to get this working with keycloak. But at this moment I'm a bit concerned about the security risk that go with this process.
The process in steps
the (plugin) client asks to backend server to generate a code to identify the user.
the (plugin) client start polling the backend for an authentication code (no response yet, since the user is not logged in yet).
the plugin opens a browser window or tab with the keycloak loginpage. Everything is the same as the normal process, but this time we add an redirect uri with the code generated in step one, which identifies the user.
once the user is logged in the user gets redirected in the browser to an endpoint where the code from step one is linked to the access token retrieved in this step.
the polling from step 2 now returns the access token to the (plugin) client.
The reason I need to poll for the access token is because I want to make a generic login process for all client.
In short, I want to know what the security risks are, given the steps above. Also I can not seem to find any information of keycloak that they want to implement such feature. Does anyone know if they want to implement this, since many other plugins do offer tis feature to authenticate outside the plugin with a popup window and retrieving the accesstoken by "polling" the server.
Thanks for the help.
I've been having some problems trying to understand the Oauth requirements for Server-side applications which don't require User interaction when querying google API's.
Apologies if this seems obvious to most, but the issue I have is that all the examples and Oauth flows are based on prompting a user to either authorize which features the application has access to or authenticate the user with a google account before being granted a token and refresh token.
Does anyone have experience querying the Sheets API from a server side app without user interaction that could give me some pointers on how to create the Auth token?
I'll be using Javascript, AJAX and JSON to call the REST API.
Many thanks,
Billy
Thanks pinoyyid, having searched this site for and hour and playing around with Oauth playground for better part of an hour, it's frustrating to know the answer was right under my nose in the settings!
Thanks again, really appreciate you pointing me to How do I authorise an app (web or installed) without user intervention? (canonical ?).
For those reading this in the future the link in the comment above will solve your problem, to summarise, you can use your own app settings by going to the google Oauth playground and on the top right select the settings (picture of a cog/gear) and ticking the box to use your app details, enter the client ID and client secret, job done.
Cheers,
Billy
We have several apps Deployed on Google Apps Marketplace using OAuth 1.0 protocol. According expiration OAuth 1.0 in Google Platform we are trying to migrate all the apps to new OAuth version but we are facing some difficulties regarding background request to Google Admin SDK Directory API.
In our apps we need to request for Domain user accounts, groups and other stuff related Email Domain structure. Until OAuth 1.0 we have been doing this with 2-LO (Two-Legge OAuth) so basically once Admin gave us access we can impersonate request for domain using this mechanism.
After reading all Google Documentation about Google API, Oauth Mechanisms and stuff, and after trying some code test hypothesis too, we haven't figured out yet how can we managed the same concept with OAuth 2 because of the following:
Using Web Server Oauth 2 Strategy simply will not work because in that scenario we would be getting a Domain user Access to Admin SDK. If we keep their access/refresh token pair to later querying Admin SDK and the user is deleted because Domain change it Admin we will be disconnected from flow.
I supposed in that case the best choice was Service Account strategy. The problem with this scenario is the user has to manually configure access to the App in their Admin Console according to the Google's document domain-wide delegation authority (https://developers.google.com/+/domains/authentication/delegation#create_the_service_account_and_its_credentials). This is really awkward for us since we were managing all application installation interactively and we don't want to remove User Experience facilities.
Finally, my questions are:
Is there any way to do domain-delegation authority with OAuth 2 with no manual user configuration, full interactively?
Is there any way to do this without needing user email, which in fact is one of the parameters in Service Account Oauth2 Strategy?
Must we keep 2-LO Authentication for this scenario and do OAuth 2 only for installation Google Marketplace part?
Any comments or guide will be wellcome.
Best,
Certainly - in the latest update to the Google Apps Marketplace, the act of installing an App means the admin doesn't need to do an additional manual step.
You need a way to impersonate a user in a Service Account. Depending on how you implement your application, you might need to utilize the Directory API.
OAuth1 is going away eventually so I recommend you use OAuth2 throughout to simplify your code complexity.
We've got a working salesforce api implementation that gets and sets properly with a production salesforce account. We've recently come across a user that rather than using their production Salesforce to connect to our implementation, has set up a sandbox for a limited trial.
I personally have a sandbox that I can properly connect to. It is not, however, connected to a production salesforce instance.
I'm wondering if the fact that they have a production salesforce instance that they created the sandbox from will affect the API login to the sandbox.
I'm currently receiving a "your salesforce login is incorrect" even though I am absolutely certain the credentials and security token are correct.
If you need any other information, I'll happily include it.
Thoughts?
Login requests for sandbox accounts should goto test.salesforce.com not login.salesforce.com. You should also login through the webapp and look in login history (in setup) that'll sometimes have more information.