SAP Launchpad Service での動的タイル実現方法 (2/3) – Cloud Foundry上のFioriアプリケーションを動的タイルとして表示する

本ブログでは主にCloud Foundry上にDeployされたSAPUI5アプリケーションをSAP Launchpad Serviceより呼び出す際の動的タイル作成方法について説明します。具体的なアーキテクチャイメージは以下のようになります。

1. SAP Launchpad Serviceにアクセスしタイルが表示されます
2. SAP Lauhchpad Serviceにログオンしたユーザーを使用してJava ApplicationのAPIをコールし、動的タイルに表示する用のパーソナライズされた数字を取得します
3. タイルをクリックするとSAPUI5アプリケーションが呼ばれます

1. SAP Launchhpad Serviceログイン時の認証フローです。XSUAAとOAuth Authorization Code Flowを使用してログオンします。
2. Java Application呼び出し時の認証フローです。Destination経由でXSUAAとOAuth JWT Bearer Token Flowを使用してJava Applicationに対してSSOします。

1. SAPUI5アプリケーションをSAP Launchpad Serviceと統合するためにはHTML5 Content providerとしてSAPUI5アプリケーションをデプロイする必要があります。従来のStandalone版Application routerを使用したデプロイ方法とは異なるので注意が必要です。動的タイルの話とは直接は関連しないので詳細について説明は本ブログではしませんが、興味のある方は以下サイトにてContent providerとするSAPUI5アプリケーションのデプロイ方法についてご確認ください。https://help.sap.com/viewer/24284cbd872f45a4bfa2f51c37cc7063/Cloud/ja-JP/3a0e6d6b791c4c2189f6a0a424188362.html
2. SAP Launchpad ServiceとSAPUI5アプリケーション、Java Applicationは全て同じサブアカウントに配備することを想定としています。基本的にXSUAAのToken(JWT)はサブアカウント内でのみ伝播が可能です。異なるサブアカウントにまたがるApplication連携は別途SSOの設計が必要になります。
3. 作成するJava ApplicationはSpring BootのRestControllerの実装とします。また認証/認可実装はSpring Security、ビルドツールはMavenを使用することとします。

 

3. 実現ステップ

<dependency>
    <groupId>com.sap.cloud.security.xsuaa</groupId>
    <artifactId>xsuaa-spring-boot-starter</artifactId>
    <version>${sap.cloud.security.version}</version>
</dependency>

またSpring SecurityのConfigurationクラスに以下のような実装を追加します。

@Override
protected void configure(HttpSecurity http) throws Exception {
    // @formatter:off
    http
        .sessionManagement()
            .sessionCreationPolicy(SessionCreationPolicy.STATELESS) // session is created by approuter
        .and()
            .authorizeRequests()
            .antMatchers("/v1/sayHello").hasAuthority("Read")
            .antMatchers("/v1/*").authenticated()
            .antMatchers("/v2/*").hasAuthority("Read")
            .antMatchers("/v3/*").hasAuthority("Read")
            .antMatchers("/v3/requestRefreshToken/*").hasAuthority("Read")
            .antMatchers("/health").permitAll()
            .antMatchers("/tokencheck").permitAll()
            .antMatchers("/jwtcheck").permitAll()
            .antMatchers("/gettestnum").permitAll()
            .antMatchers("/").permitAll()                                             
            .anyRequest().denyAll()
        .and()
            .oauth2ResourceServer()
            .bearerTokenResolver(new IasXsuaaExchangeBroker(xsuaaTokenFlows))
            .jwt()
            .jwtAuthenticationConverter(getJwtAuthenticationConverter());
}

/**
* Customizes how GrantedAuthority are derived from a Jwt
*/
Converter<Jwt, AbstractAuthenticationToken> getJwtAuthenticationConverter() {
    TokenAuthenticationConverter converter = new TokenAuthenticationConverter(xsuaaServiceConfiguration);
    converter.setLocalScopeAsAuthorities(true);
    return converter;
}

上記実装によりOAuthの認証/認可、および、特に後半”.and”以降の実装にてOAuthのAccess tokenがThreadLocalに格納され、RestControllerよりAccess Tokenが使用可能になります。

それでは次にRestControllerの実装について説明します。

@GetMapping("/gettestnum")
public int gettestNum(@AuthenticationPrincipal Token token) {
    System.out.println("Come here!!!");
    if (token == null) {
        System.out.println("token is null.....");
        return 0;
    }
    System.out.println("Got the Xsuaa token: " + token.getAppToken());
    System.out.println("grant type: " + token.getGrantType());
    System.out.println("client id: " + token.getClientId());
    System.out.println("subaccount id: " + token.getSubaccountId());
    System.out.println("zone id: " + token.getZoneId());
    System.out.println("logon name: " + token.getLogonName());
    System.out.println("family name: " + token.getFamilyName());
    System.out.println("given name: " + token.getGivenName());
    System.out.println("email: " + token.getEmail());
    System.out.println("authorities: " + String.valueOf(token.getAuthorities()));
    System.out.println("scopes: " + String.valueOf(token.getScopes()));
    //
    // 色々なJWTのAttributeで処理を分岐
    //
    return 3;
}

こちらの実装でFramework内に格納したAccess TokenをMethodの引数にInjectしてRestContoroller内で使用します。この実装では実際ではあり得ない実装ですがTokenがない場合(=OAuth serverとやりとりせずに直にAPIが呼ばれる場合)0を返し、それ以外では3を返します。実際にはTokenがない場合はConfigurationファイルにてアクセス不可設定をし、Access Tokenの中身によりパーソナライズした数字情報をSAP Launchpad Service側に返す実装になります。なおこちらの標準出力の実装を見ればTokenに何が含まれていて、どのようにパーソナライズしたハンドリングが可能かイメージがつくかと思います。例えばメールアドレスをキーにデータをアグリゲートして値を返すような実装が可能です。

なおAccess TokenにDefaultで含まれない属性をパーソナライズする際に使用したい場合、IASの任意の値をAccess Tokenに含めることも可能です。その場合XSUAAサービスを作成する際、xs-security.jsonに追加属性を指定する形になりますが詳細な実装はここでは触れずにおきます。これでJava Applicationの実装は終了です。

{
  "xsappname": "spring-security-xsuaa-usage",
  "oauth2-configuration": {
    "credential-types": ["x509"]
  },
  "tenant-mode": "dedicated",
  "scopes": [
    {
      "name": "$XSAPPNAME.Read",
      "description": "Read Permissions."
    },
    {
      "name": "$XSAPPNAME.Admin",
      "description": "Admin permissions."
    }
  ],
  "role-templates": [
    {
      "name": "Viewer",
      "description": "View Data",
      "scope-references": [
        "$XSAPPNAME.Read",
        "uaa.user"
      ]
    },
    {
      "name": "Administrator",
      "description": "View Sensitive Data",
      "scope-references": [
        "$XSAPPNAME.Read",
        "$XSAPPNAME.Admin"
      ]
    }
  ],
  "role-collections": [
    {
      "name": "Viewer",
      "description": "Viewer (read)",
      "role-template-references": [
        "$XSAPPNAME.Viewer"
      ]
    },
    {
      "name": "Administrator",
      "description": "Administrator (read all)",
      "role-template-references": [
        "$XSAPPNAME.Administrator"
      ]
    }
  ]
}​

1. SAP Launchpad Serviceログイン時にXSUAAより取得したAccess TokenをDestinationに渡します。
2. DestinationサービスはOAuth JWT Bearer Token Flowに則り#2-1で受け取ったAccess Tokenを使用してXSUAAのToken EndpointをCallします。
3. 受け取ったAccess Tokenの妥当性を判断し問題ない場合、上記したJava Application用のAccess Tokenを返します。このAccess TokenにJava ApplicationのOAuthアプリケーション情報が含まれています。この情報はこれまた上記で作成したXSUAAサービスの登録情報そのものです。
4. Destinationサービスは取得したJava Application用のAccess TokenをManaged Application Routerに返します。
5. 最後にManaged Application Routerは取得した新しいAccess Tokenを使用しJava Application APIをCallします。

dataSourceに上記で作成したDestinationサービス名、pathにはDestinationサービスで指定したJava ApplicationのURLに加えて、実際のEndpointのPathを指定する形になります。その際必ず/dynamic_destをpathの先頭に含めることを忘れないでください。奇妙な感じもしますがこれはSAP Launchpad Serviceの仕様です。

このSAPUI5をCloud Foundry環境にDeployするとSAP Launchpad Serviceのコンテンツマネージャで以下のように値が反映されていることが確認できます。

繰り返しになりますが肝はManaged Application Routerを中心としたOAuth JWT Bearer Flowの取り回しです。同じサブアカウントにて認証を行う際、同じXSUAAを使用するためコンポーネント間のAccess Tokenの引き回しが簡単に行えます。これは今回の例で説明した動的タイルに限らない話です。サブドメイン内のApplication to Applicationの呼び出しが必要な場合にも応用が効く話なので是非覚えておいてください。それでは楽しいSAP開発ライフを！