Archive for 9月, 2020
WebLogic on Azure VM が正式リリース
Azure Linux 仮想マシンで OracleWebLogic Server(WLS)が正式に利用可能になったことをお知らせします。
このリリースは、Microsoft と Oracle の幅広いパートナーシップの一環として、WebLogic チームと共同で開発しました。
このパートナーシップには、Oracle/Microsoft および Azure で実行されているさまざまな Oracle ソフトウェアのサポートも含まれます。
Azure AD で OpenID Connect を使用したセキュアな Open Liberty アプリケーションの構築
* Application Development
* Cloud
* Tutorials and Demos
* Community/partners
Web アプリケーションで、ユーザーアカウントを独自に作成したり、認証・認可を個別に実装・管理する時代は終わりました。
その代わりに、現在のアプリケーションは、外部プロバイダーを利用して、上記の機能(Identity and Access Management略してIAM)を実装します。 完全な Javaアプリケーションの実行基盤として存在する、Open Liberty は、外部プロバイダーの IAM を利用するための機能を備えています。Open Liberty はソーシャルメディア・ログイン、SAML Web シングルサインオン、OpenID Connect クライアントなど IAM の主要な機能をサポートしています。
Bruce Tiffany のブログ・エントリ 「Securing Open Liberty apps and microservices with MicroProfile JWT and Social Media login」では、Open Liberty ソーシャルメディア・ログインの機能を使用して、既存のソーシャルメディアの認証情報を使用してユーザー認証する方法を紹介しています。
このブログ・エントリでは上記とは別の方法をご紹介します。ここで Microsoft の Azure Active Directory で Java アプリケーションを保護するために、Liberty ソーシャルログイン機能を OpenID Connectクライアントとして実装する方法を見てみましょう。
このブログで紹介するサンプルコードは、全て コチラの GitHub リポジトリで公開しています。ブログをご覧頂く前後で、コードをチェックし、ユーザーガイドに従い Java EE サンプル・アプリケーションを実行してください。
Azure Active Directory のセットアップ
Azure Active Directory(Azure AD)は、認証プロトコルとして OAuth 2.0 上に OpenID Connect(OIDC)を実装しているため、Azure AD を利用したアプリケーションのセキュアなユーザー認証ができるようになっています。
サンプルコードをご覧いただく前に、Azure AD テナントをセットアップし、リダイレクト URL の設定とクライアントシークレットでアプリケーションを登録してください。
Azure AD のテナント・セットアップ時に取得する、テナントID、アプリケーション(クライアント)ID、およびクライアントシークレットは、Open Liberty が Azure AD と接続し OAuth 2.0 承認フローを行うために使用しますので情報を控えておいてください。
Azure AD の設定方法は、下記の記事をご参照ください。
* クイック スタート:テナントを設定する
* クイック スタート:Microsoft ID プラットフォームにアプリケーションを登録する
* 新しいアプリケーション シークレットを作成する
OpenID Connect クライアントとしてソーシャルログインを構成
下記のサンプルコードは、Open Liberty サーバーで実行されているアプリケーションが、どのようにして、Azure AD を使用した OpenID Connectプロバイダーに対して、socialLogin-1.0 の機能を持つ OpenID Connect クライアントからユーザー認証を行うのか、その方法を示しています。
関連するサーバー構成:server.xml
oidcLogin 要素は、Open Liberty が持つ多数の設定可能要素の一つです。
サンプル・コードで示すように、Azure AD は検出用のエンドポイントをサポートしているため、Azure AD を利用する場合、多くの設定は不要で、サンプル・コードで示すように、いくつかのオプションのみを使用します。
検出用のエンドポイントを利用すると、ほとんどの OpenID Connect の設定情報をクライアントが自動的に取得できるため、設定が大幅に簡素化できます。
さらに、特定の Azure AD インスタンスは、検出用エンドポイント URL に対して既知のパターンを適用するため、テナントID を使用して、URL をパラメーター化することもできます。
また、クライアントIDとシークレットが必要で、署名アルゴリズムとして RS256 を使用します。
userNameAttribute 属性は、Azure AD のトークンと Liberty の一意のサブジェクト ID にマップするために使用します。
使用可能な Azure AD トークンは、この一覧に示すようにいくつかあります。
v1.0 と v2.0 で必要なトークンは異なるため、注意が必要です(v2.0は一部のv1.0トークンをサポートしていません)。
preferred_username もしくは oid は共に安全に使用できますが、通常 preferred_username の使用をお勧めします。
Azure ADを使用すると、アプリケーションは、Microsoft の認証局 (Root CA) によって署名された証明書を使用できます。
この証明書を、JVM のデフォルトの cacerts に追加します。 JVM のデフォルトの cacerts を信頼することで、OIDC クライアントと Azure AD 間で SSL ハンドシェイクが成功することが保証されます(つまり、defaultSSLConfig trustDefaultCerts値を true に設定する)。
この場合、Azure AD を介して認証されたすべてのユーザーにユーザーロールを割り当てます。必要に応じて、Liberty でより複雑なロールマッピングも可能です。
OpenID Connect を使用したユーザー認証
サンプル・アプリケーションは JSF アプリとして公開します。ここでは “users” のロールを持つユーザーのみがアクセスできる Java EE セキュリティ規約を定義しています。
web.xmlの関連構成:
GitHub の web.xml へのリンクはコチラ
ワークフロー
図1:Azure AD で OpenID Connect を利用したトークン取得フロー
これは Java EE の標準セキュリティです。
認証されていないユーザーが JSF のアプリケーションに対してアクセスしようとすると、Azure AD の資格情報を取得するために Microsoft のサイトにリダイレクトされます。
成功すると、ブラウザは認証コードを含んでクライアントにリダイレクトします。
次に、クライアントは、再度 Microsoft のサイトに接続し、認証コード、クライアントID、シークレットを使用して IDトークンとアクセストークンを取得します。最後に、クライアントで認証済みユーザーを作成し、JSF アプリに対してアクセスします。
認証されたユーザー情報を取得するには、@ Injectアノテーションを使用してjavax.security.enterprise.SecurityContextへの参照を取得し、getCallerPrincipal() メソッドを呼び出します。
GitHub の Cafe.java へのリンクはコチラ
JWT RBACを使用したセキュアな内部 RESTful 呼び出し
JAX-RS で実装した RESTful Web サービスである Cafe Bean は CafeResource に依存し、コーヒーの作成、読み取り、更新、削除を行います。
CafeResourceは、MicroProfile JWT を使用して RBAC(ロールベースのアクセス・コントロール)を実装し、トークンのグループ要求を検証します。
GitHub の CafeResource.java へのリンクはコチラ
admin.group.id は、ConfigProperty アノテーションで定義する事で、MicroProfile Config を使用し、アプリケーションの起動時に値を注入します。
MicroProfile JWT では JWT(JSON Web トークン)を @Inject で注入きます。
CafeResource REST エンドポイントは、OpenID Connect の承認ワークフローに従い、Azure AD によって発行された ID トークンから、preferred_username および groups クレームを含む JWT を受け取ります。
ID トークンは、com.ibm.websphere.security.social.UserProfileManager およびcom.ibm.websphere.security.social.UserProfile API を使用して取得できます。
関連する設定:server.xml
GitHub の server.xml へのリンクはコチラ
注意:
グループ claim はデフォルトでは伝搬されないため、Azure AD の追加設定が必要です。
ID トークンにグループ claim を 追加するためには、Azure ADでタイプが「セキュリティ」のグループを作成し、1 名以上のメンバーをそのグループに追加する必要があります。
Azure AD の設定で、アプリケーションの登録時に、下記の情報を取得する必要があります。
「Token configuration」 を選択> 「Add groups claim」 を選択 >「セキュリティグループ」を選択(ID トークンを含むグループ) >「ID」を展開 > 「Customize token Properties」から「Group ID」を選択
詳細はコチラをご覧ください。
* Azure Active Directory を使用して基本グループを作成してメンバーを追加する
* グループの省略可能な要求を構成する
まとめ
このブログエントリでは、OpenID Connect と Azure Active Directory を使用してOpen Libertyアプリケーションを効果的にセキュアにする方法を示しました。
ここの記載内容に加え、オフィシャルの Azure サンプルも、WebSphere Liberty 上で簡単に動作します。
この取り組みは、Jakarta EE (Java EE)、および MicroProfile を使用する開発者に有用な情報とツールを提供するため、Microsoft と IBM が協力してできた物の一つです。
* Java EE はベンダー中立のオープンソースガバナンスの下で Jakarta EE として Eclipse Foundation に移管されました
* MicroProfileは、Java EEテクノロジーに基づいて構築され、マイクロサービスドメインを対象とする一連のオープンソース仕様です
どのようなツールやガイダンスが必要かご意見をお聞かせください。
また、特に、クラウド・マイグレーションにご興味があり、(無償で)私たちと緊密に連携したいご要望がある場合、
可能でしたら、このブログ・エントリに関する 5 分間のアンケートにご協力・ご記入頂き、貴重なフィードバックをください。
どうぞ宜しくお願いします。