Jira の認証

Jira のアクティビティまたはトリガーを使用する前に、UiPath Integration Service で Jira Cloud インスタンスへのコネクションを作成する必要があります。

重要:

Jira コネクタは Jira Cloud インスタンスのみをサポートします。Jira Server および Data Center インスタンスはサポートされていません。

サポートされている認証方法 (Jira Cloud のみ)

認証の種類	説明	最適な用途
API トークン (HTTPS 経由の基本)	Atlassian Cloud のメールと API トークンを使用します。	サービス アカウント、無人オートメーション
OAuth 2.0	ユーザーのサインインと Jira Cloud のスコープへの同意を使用します	ユーザー委任フロー、Attended フロー、または個人用フロー。
独自の OAuth 2.0 アプリ (BYOA) を使用する	UiPath のコールバック URL で独自の OAuth アプリを使用します。	お客様が自身の Jira アプリとキーを管理する

API トークン (HTTPS 経由の基本)

HTTPS 基本認証として渡される、Atlassian アカウントのメール アドレスと API トークンを使用して Jira Cloud で認証します。詳細情報。

コネクションは、設定した Jira ユーザーと同じプロジェクト権限と課題権限で実行されます。

必須フィールド

フィールド	説明
サイト URL	Jira サイトの URL ( 例: https://your-domain.atlassian.net)。 注: URL の末尾に「https://」を含め、末尾に「/」を含めないでください。
ユーザー名	Jira Cloud へのログインに使用される Atlassian アカウントのメール アドレス
API トークン	アカウントに関連付けられた Jira Cloud API トークン

API トークンの生成方法

1. Atlassian Account Security で API トークン (スコープなし) を作成します。詳細情報。
2. 生成されたトークンをコピーし、後で使用するために安全に保管しておきます。
3. UiPath Integration Service で Jira コネクションを追加し、次のように入力します。

• サイト URL
• ユーザー名
• API トークン

トークンのライフサイクル

セキュリティ上の理由から、トークンの有効期限は 1 年以内で、Atlassian アカウントの [セキュリティ] ページから取り消したり削除したりできます。削除されると、そのトークンを使用するすべての Integration Service 呼び出しは、新しいトークンが設定されるまで 401 Unauthorized で失敗します。

トラブルシューティング

• 401 Unauthorized: Check email and token, confirm the token exists and was copied correctly. (401 認可されていません: メールとトークンを確認し、トークンが存在し、正しくコピーされたことを確認します)。
• 403 Forbidden on some operations: Jira ユーザーが対象のプロジェクトと課題タイプに対して必要なプロジェクト権限を持っていることを確認します。

よくある質問

API トークンを特定のプロジェクトに制限できますか?
いいえ。トークンは、ユーザーのすべての権限を継承します。Jira でユーザー/プロジェクトの権限を設定して、アクセスを制限します。

CAPTCHAまたはSSOはトークンベースの呼び出しに影響しますか?
CAPTCHAおよびインタラクティブログインルールは、APIトークンではなくユーザー名/パスワードに適用されます。SSO は引き続きアカウントを管理しますが、トークンの使用はブロックされません。詳細情報。

UiPath で使用されるトークンはどのようにローテーションすればよいですか?
新しいトークンを作成し、UiPath の Jira 接続を新しいトークンで更新し、オートメーションを検証してから、古いトークンを取り消します。

独自の OAuth 2.0 アプリ (BYOA) を使用する

この認証の種類は OAuth 2.0 認可コードに似ていますが、独自のクライアント ID とクライアント シークレットの資格情報を使用する必要があります。

独自のアプリの作成に関する Jira のガイドライン「 OAuth 2.0 (3LO) apps」に従います。アプリケーションは Jira 開発者コンソールから作成できます。独自の OAuth2.0 を設定する場合アプリ: 必ずリダイレクト/コールバック URL を次のように指定してください。 https://cloud.uipath.com/provisioning_/callback
これは、オートメーションをエンド ユーザーのコンテキストで実行し、OAuth スコープとそのユーザーのプロジェクト権限の両方に従う必要がある場合に推奨されます。

必須フィールド

フィールド	説明
サイト URL	Jira サイトの URL です (例: https://your-domain.atlassian.net)。Jira にアクセスする権限を UiPath アプリに付与するよう求められたら、同じ Jira サイトの URL を選択してください。
クライアント ID	Atlassian OAuth 2.0 (3LO) アプリのクライアント識別子です。
クライアント シークレット	Atlassian OAuth 2.0 (3LO) アプリのシークレット。これは UiPath Integration Service データベースに保存されます。
リダイレクト URL	UiPath コールバック URL。Atlassian アプリ内で正確に設定されています。
ユーザー名	Jira のログイン ページで使用します。
パスワード	Jira のログイン ページで使用します。

Jira のスコープを理解する

スコープは、アプリが Atlassian 製品と対話するために要求できるアクセス レベルを定義します。コネクションが確立され、ユーザーが Jira アクティビティを通じて (API 経由で) アプリを認可すると、OAuth アプリはユーザーに代わって、指定された操作を実行する権限を得られます。この権限は、ユーザーの権限設定に応じて付与されます。利用可能なスコープの完全なリストについては、「 Jira スコープ」をご覧ください 。

以下の表に、コネクションの作成に必要なスコープを示します。

スコープ	入力	説明
読み取り:jira-user	Required	ユーザーがアクセスできる Jira でユーザー情報 (ユーザー名、メール アドレス、アバターを含む) を表示する。
読み取り:jira-work	Required	Jira プロジェクトと課題データを読み取り、課題や、添付ファイルや作業ログなどの課題に関連付けられたオブジェクトを検索します。
書き込み:jira-work	Required	Jira での課題の作成と編集、ユーザーとしてのコメントの投稿、ワークログの作成、課題の削除を実行できます。
管理:jira-project	Required	プロジェクト設定を作成および編集し、新しいプロジェクトレベルのオブジェクト (バージョンやコンポーネントなど) を作成します。
offline_access	Required	OAuth トークンを自動的に更新する
管理:jira-configuration	任意です。	Jira 管理アクション (プロジェクトとカスタム フィールドの作成、ワークフローの表示、課題リンク タイプの管理など) を実行します。
管理:jira-data-provider	任意です。	Jira でサードパーティの開発およびリリース情報を管理する

重要:

アプリには、コネクションが要求するすべてのスコープが必要です。

資格情報の生成方法

1. アトラシアンの 3LO アプリ ガイドに従ってください。
2. Integration Service の [Jira 認証] ページで取得した UiPath Jira コールバック URL をリダイレクト URI として設定します。
3. 必要な Jira Cloud のスコープを選択します (例: read:jira-work、 write:jira-work、 read:jira-user)。
4. クライアント ID とクライアント シークレットを Atlassian アプリから UiPath Jira の接続設定にコピーします。

トークンのライフサイクル

アクセス トークンは短命です。UiPath は、更新トークンの有効期限が切れるか取り消されるまで、更新トークンを使用して新しいアクセス トークンを取得します。

同意を取り消すか Atlassian OAuth アプリを削除するとトークンが無効になるため、UiPath による再承認が必要になります。

トラブルシューティング (OAuth)

• リダイレクト URI の不一致: Atlassian で設定されたリダイレクト URL が UiPath のコールバック URL と完全に一致していることを確認します。

• insufficient_scope または 403: 不足している Jira スコープをアプリに追加し、必要な Jira 権限をユーザーに付与します。

よくある質問

CRUDを発行するための最小範囲は何ですか?
オブジェクトによって異なりますが、通常は問題/コメントに対して read:jira-work および write:jira-work します。ユーザーの検索/割り当てを使用する場合は read:jira-user を追加します。

スコープで特定のプロジェクトへのアクセスを制限できますか?
いいえ。スコープは機能します。プロジェクト レベルのアクセスは、これまでと同様に Jira での承認ユーザーの権限によって管理されます。

OAuthログインが成功しても403が表示されるのはなぜですか?
限定公開アプリで read:jira-user が推論されていることを確認します。

OAuth 2.0 の認可コード

UiPath Integration Service の OAuth 2.0 認可コードのメソッドは、Jira Cloud でのトークンの取得方法やアクティビティの実行方法において、独自の OAuth 2.0 アプリ (BYOA) を使用するのと機能的に同じです。主な違いは、OAuth アプリケーションの資格情報の所有者です。

• OAuth 2.0 認可コードは 、事前に設定されたスコープが制限された、UiPath が独自に登録した Jira Cloud 用の OAuth 2.0 アプリケーションを使用します。
  • つまり、クライアント ID とクライアント シークレットは UiPath によって管理され、ユーザーが要求する必要はないということです。
  • ユーザーは、コネクションの設定時に Jira サイトの URL を指定して目的のスコープを選択するだけです。
  • ユーザー ログイン、同意、トークンの管理など、その他の認証操作はカスタム アプリと同じです。
• BYOA (Bring Your Own OAuth) を使用すると、組織は独自の OAuth 2.0 アプリをアトラシアンに登録して管理できます。
  • ユーザーまたは管理者は、カスタム アプリのクライアント ID とクライアント シークレットを指定し、それに応じてコールバック URL を構成する必要があります。
  • 組織にプライベート アプリが必要な場合、独自のキーを管理する場合、または OAuth クライアント構成にガバナンスを適用する必要がある場合は、BYOA を使用します。

必要な範囲、同意フロー、利用可能な機能に違いはありません。どちらも Atlassian の 3-legged OAuth を使用して、Jira Cloud 用のユーザー付与アクセス トークンを取得します。唯一の違いは、UiPath のパブリック連携 (クライアント資格情報は不要) を使用しているか、独自の Atlassian OAuth アプリ (セットアップ時に資格情報が必要) を使用しているかです。