I'm trying to use JIRA API for creating story, task or bug on JIRA tool but account needs to be login first for performing all operations. I have my Azure AD account used for JIRA login on UI but I'm unable to find a way to login using JIRA API. Community, please help here.
Jira's REST API can't use Azure credentials for authentication. Depending on whether you're connecting to Jira Cloud or Jira Server, it uses OAuth, keys and tokens, or usernames and passwords.
Refer to this Security overview page for all the methods supported.
Related
My Atlassian Jira Login API POST -(https://Domain .atlassian.net/rest/auth/1/session) is not working .It is always returning UnAuthorized Response
Header
{"username":"username#xx.com" ,"password":"xxxxx"}
First, the endpoint /rest/auth/1/session has been removed from Jira Cloud with the end of last year. See this announcement by Atlassian from last year.
Second, if you want to authenticate requests to Jira Cloud using Basic Authentication, you need to use an API token for your user. This is also explained in the first sentence of the linked announcement above.
Atlassian has introduced support for API tokens for all Atlassian Cloud sites as a replacement for basic authentication requests that previously used a password or primary credential for an Atlassian account, as well as cookie-based authentication.
I'm a bit new to the authentication/authorization landscape and need some advice on how to architect/implement an application that will ultimately be connecting to Salesforce and retrieving information. At a very high-level, I'm building a mobile app that will need to pull Salesforce related data to display to the user. Their specific Salesforce instance uses Google as the identity provider. Also, we are planning to put a gateway in place to orchestrate all communication with Salesforce and potentially do some response aggregation. We're also planning on using Cognito to handle the identity management. My specific questions are:
Will I be authenticating through the Salesforce auth endpoints? If Salesforce is ultimately using Google as an identity provider, wouldn't it make sense to retrieve that token directly from Salesforce itself?
Will I need to register the mobile app as an application as well within Salesforce or Google? I understand that Salesforce itself needs registered within Google to allow for using Google as an identity provider in Salesforce, but does it make sense to register both?
There is currently no need to restrict resource access, as any user that can log in can see everything. Will that effect the implementation at all? Essentially, if a user can log into Salesforce with their Google creds (a.k.a they have a user mapped), then they should be able to see anything.
I'm sure that I'm asking some naive quesitons, and really don't know where to start. I've recently build an Api for Salesforce Connect's use using Azure as an identity provider and that was fairly straightforward, though that was machine-to-machine and much simpler. Any help at all would be greatly appreciated. Thank you.
It has been a while... not sure you still have an issue.
Assuming salesforce is configured to use Google for auth/as an Auth Provider: you have to have your app auth to salesforce, and salesforce will automatically redirect the user to auth to Google (or ensure there is an existing valid Google user session, and let you access salesforce). Google with issue a token to salesforce, and salesforce will issue its own token to your app.
I am using https://docs.wso2.com/display/CLUSTER44x/Configuring+the+Pre-Packaged+Identity+Server+5.2.0+with+API+Manager+2.0.0 Where my API's are managed in API manager and users are in WSO2 Identity server database. Now we are migrating to gmail based social auth. we are getting rid of the database and every user will be using gmail social auth.
How to achieve this using WSO2 Identity manager? Can scopes work along with this?
How can I handle the login/redirect pages in these scenarios?
You can add Google as a federated authenticator to the WSO2 IS. After that whenever you login, Google will be used as the authenticator instead of internal IS user store.
If you are talking about Google level scopes, yes you can manage that. It is shown in the documentation[1] or if you are talking about the API manager level scopes, nothing will affect that.
When you are authenticating, IS will automatically redirect you to the Google login page.
[1] https://docs.wso2.com/display/IS520/Configuring+Google
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.
I have a large customer base and would like to migrate them from using OAuth1 2LO to OAuth2 Domain-Wide Delegation and
1) Would like to know if it's possible.
2) If possible, can it be done without user intervention/impact.
For reference, I am looking at/following the OAuth1 migration doc (https://developers.google.com/accounts/docs/OAuth_ref#migration):
According to the delegation docs, we'd want to create a "service account", but the OAuth1 -> OAuth2 migration guide (https://developers.google.com/accounts/docs/OAuth_ref#migration)
Your application must have an OAuth 2.0 Client ID. You get this Client ID by registering the application as an installed app or a web app in the Google Cloud Console.
1) Does this also work for "service accounts"?
If the migration does work for service accounts, there appear to be manual steps on the part of the admin for setting up delegation (found here: https://developers.google.com/drive/delegation)
The service account that you created now needs to be granted access to the Google Apps domain’s user data that you want to access. The following tasks have to be performed by an administrator of the Google Apps domain:...
2) Does this mean that we will require our customers to complete these steps ?
Any help would be appreciated
There is no token migration involved for the delegation case (so, ignore the migrations docs: https://developers.google.com/accounts/docs/OAuth_ref#migration).
In order to migrate to OAuth2 in this case, you will have to implement Google's 2-legged OAuth2. For information on how to do so, check out Google's 2-legged OAuth2 and Google Drive SDK delegation docs.
Hope that helps!