はじめに

SAP S/4HANA のSide-by-Side拡張開発という文脈でも、SAP BTP上でSAP CAPのアプリケーションを作成し、カスタムロジックを作成することはよくあるユースケースです。本ブログ記事では、その際にカスタムアプリケーションへのアクセス権限はどのように管理するのか、という点について、SAP Cloud Identity Servicesを用いた管理の一例をご紹介します。

目次

SAP Cloud Identity Services とは？SAP CAPアプリケーションにおける権限管理SAP CAPアプリケーションのサービス定義とロールの設定SAP Cloud Identity Services – Identity Authenticationのユーザーグループによる権限管理

1. SAP Cloud Identity Services とは？

SAP Cloud Identity Servicesは、SAP BTP上で提供されるクラウドベースのセキュリティサービス群であり、企業がアイデンティティとアクセス管理を効果的に行えるよう支援します。主に以下の特徴と構成要素から成り立っています。

特徴

中央集権管理：ユーザーのアイデンティティとアクセス権限を一元的に管理できます。これにより、セキュリティポリシーの一貫性が保たれ、管理作業が効率化されます。多様な認証オプション：多因子認証やリスクベースの認証など、様々な認証方法をサポートしています。これにより、セキュリティを強化しつつ、ユーザーフレンドリーなアクセスが可能です。クロスプラットフォーム対応：SAPの製品だけでなく、他の多くのクラウドサービスやオンプレミスのシステムとも統合可能です。これにより、広範囲のアプリケーションとサービスにわたって安全なアクセスが保証されます。

槇成要素

Identity Authentication Service (IAS)：認証サービスで、ユーザーのアイデンティティを確認し、セキュアな認証プロセスを提供します。ログイン試行時のユーザー検証や、認証データの保護などが行われます。Identity Provisioning Service (IPS)：アイデンティティプロビジョニングサービスで、ユーザーアカウントの作成、更新、削除などを自動化します。システム間でのアイデンティティ情報の同期も行うため、ユーザー管理がスムーズに実行されます。

これらの特徴と構成要素を通じて、SAP Cloud Identity Servicesは企業のデジタル変革を安全かつスムーズに支援します。

2. SAP CAPアプリケーションにおける権限管理

Web アプリケーションにおける認証は、アプリケーションのセキュリティを担保するために必要不可欠です。認証プロセスでは、ユーザーの身元を確認し、リクエストの正当性（例えば、ロールやテナントのメンバーシップ）を検証します。SAP CAPでは、この認証方法は多岐にわたってカスタマイズ可能であり、一般的なシナリオをカバーする標準的な認証方法がサポートされています。

例えば、SAP BTP上で提供されているXSUAA（XS User Authentication and Authorization）サービス はOAuth 2.0に準拠した認証サーバーで、JWTトークンを通じてユーザー情報と認証情報を提供します。

https://cap.cloud.sap/docs/guides/security/authorization

中でも今回は、SAP CAPアプリケーションの認証実装でよく用いられるこのXSUAA形式での認証を前提にご紹介いたします。

どの認証方式を利用するのか、という設定はpackage.jsonにて行います。 cds -> requires -> auth の値をxsuaa として設定を行なっておく必要があります。この辺りの詳しい説明は上記公式ドキュメントをご参照ください。

package.json

“cds”: {
“requires”: {
“[production]”: {
“db”: “hana”,
“auth”: “xsuaa”
},
“app-service”: {
“impl”: “@sap/low-code-event-handler”
},
“auth”: {
“[development]”: {
“kind”: “dummy”
},
“[production]”: {
“kind”: “xsuaa”
}
}
},
“features”: {
“fetch_csrf”: true
}
},

3. SAP CAPアプリケーションのサービス定義とロールの設定

SAP CAPアプリケーションでは、一般に db/schema.cds で定義したデータモデルに対して、ODataサービスを定義して外部に公開します。この作業はsrv/service.cdsで行われ、下記のコードスニペットのように定義が行われます。(ファイル名は文脈に応じて変わる可能性もあります)

service.cds

using { cakeshop as my } from ‘../db/schema.cds’;

@path : ‘/service/cakeshop’
service cakeshopSrv
{
annotate Cake with @restrict :
[
{ grant : [ ‘*’ ], to : [ ‘store-manager’ ] },
{ grant : [ ‘*’ ], to : [ ‘store-staff’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-supervisor’ ] }
];

annotate Category with @restrict :
[
{ grant : [ ‘*’ ], to : [ ‘store-manager’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-staff’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-supervisor’ ] }
];

annotate Order with @restrict :
[
{ grant : [ ‘*’ ], to : [ ‘store-manager’ ] },
{ grant : [ ‘*’ ], to : [ ‘store-staff’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-supervisor’ ] }
];

@odata.draft.enabled
entity Cake as
projection on my.Cake;

@odata.draft.enabled
entity Category as
projection on my.Category;

@odata.draft.enabled
entity Order as
projection on my.Order;
}

annotate cakeshopSrv with @requires :
[
‘authenticated-user’,
‘store-manager’,
‘store-staff’,
‘store-supervisor’
];

このファイルでは、定義されたデータモデルを読み込み、それぞれのデータモデルを単一のODataサービス内のEntityとして公開しています。今回はケーキの在庫や注文を管理するという例になっています。

この際 @restrict アノテーションを通じて、各EntityやODataサービス自体に対してCRUD操作の制限をかけることが可能です。今回は 以下のように分割された操作権限が定義されています。

ロール名

対象

エンティティと権限

Cake

Category

Order

authenticated-user

認証されたユーザー全般

–

–

–

store-manager

店舗マネージャ

CRUD

CRUD

CRUD

store-staff

店舗スタッフ

CRUD

R

CRUD

store-supervisor

エリアマネージャ

R

R

R

この定義を行ったのち、ターミナルにて以下のコマンドを実行すると、これに基づいてロールの定義（xs-security.json）が生成されます。

cds compile srv/ –to xsuaa > xs-security.json

xs-security.json

{
“scopes”: [
{
“name”: “$XSAPPNAME.store-manager”,
“description”: “store-manager”
},
{
“name”: “$XSAPPNAME.store-staff”,
“description”: “store-staff”
},
{
“name”: “$XSAPPNAME.store-supervisor”,
“description”: “store-supervisor”
}
],
“attributes”: [],
“role-templates”: [
{
“name”: “store-manager”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.store-manager”
],
“attribute-references”: []
},
{
“name”: “store-staff”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.store-staff”
],
“attribute-references”: []
},
{
“name”: “store-supervisor”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.store-supervisor”
],
“attribute-references”: []
}
]
}

これにより、このアプリケーションのデプロイと同時にロールがSAP BTP Cockpit上から利用できるようになります。

4. SAP Cloud Identity Services – Identity Authenticationのユーザーグループによる権限管理

無事にSAP CAPアプリケーションのデプロイが完了すると、下図のように、アプリケーションに紐づいたロールがデプロイされます。

SAP BTP上では、このロール群をまとめたロールコレクションという単位で権限の制御を行うため、まずはこのロールコレクションの作成を行います。

今回は、それぞれのロールに対して1つのロールコレクションを作成しました。必要があれば、一つのロールコレクションに複数のロールを割り当てることも可能です。

それでは最後に、このロールコレクションをSAP Cloud Identity Services – Identity Authenticationのユーザーグループに紐づけていきます。セキュリティ -> 認証設定から、SAP BTPを利用する際の認証に関する設定を行うことができます。今回はすでにSAP Cloud Identity Services – Identity Authenticationテナントの紐付けが済んでいるため、Custom IAS tenantの設定画面に入ります。

ロールコレクションマッピングの設定にて、先程作成したロールコレクションと、SAP Cloud Identity Services – Identity Authenticationにおけるユーザーグループを対応させます。

SAP BTP Cockpit側で行う作業は以上です。次に、SAP Cloud Identity Services – Identity Authenticationの管理者画面側で、ユーザーグループの作成とユーザーの割り当てを行います。まずは全てのEntityに対してRead権限のみを持つstore-supervisorにユーザーを割り当てます。

この状態でアプリケーションにアクセスすると、以下のような画面になります。store-supervisor ロールを持つユーザーはCake Entity に対してCreate権限を持たないため、「作成」ボタンをクリックすると、Forbiddenが返ります。

そこで、SAP Cloud Identity Services – Identity Authentication の管理者画面から、ユーザーのロールをstore-managerに変更します。

すると、store-managerロールはCake Entityに対するCreate権限を持つため、「作成」ボタンをクリックするとエラーなく作成ページを開くことができるようになります。

まとめ

本ブログでは SAP CAPカスタムアプリケーションにおけるアクセス権限の管理について、SAP Cloud Identity Servicesを使用する方法を解説しました。具体的には、SAP Cloud Identity Servicesの特徴や構成要素の説明、SAP CAPアプリケーションでの認証方法の設定、サービス定義とロールの定義方法、そして最終的にIdentity Authenticationのユーザーグループを通じた権限管理のプロセスをご紹介しました。

今回のブログには含まれていませんが、SAP Cloud Identity Services – Identity Provisioningを組み合わせると、SCIMプロトコルに従ってユーザーやユーザーグループをSAP Cloud Identity Services – Identity Authenticationに連携し、他システムで管理されているユーザーに対しても、間接的に権限管理を行うことが可能です。

SAP BTPにおけるSide-by-Side開発とは切っても切り離せない関係性のSAP Cloud Identity Servicesですが、このブログを足がかりにして、ぜひより深く学んでみてください。

​ はじめにSAP S/4HANA のSide-by-Side拡張開発という文脈でも、SAP BTP上でSAP CAPのアプリケーションを作成し、カスタムロジックを作成することはよくあるユースケースです。本ブログ記事では、その際にカスタムアプリケーションへのアクセス権限はどのように管理するのか、という点について、SAP Cloud Identity Servicesを用いた管理の一例をご紹介します。 目次SAP Cloud Identity Services とは？SAP CAPアプリケーションにおける権限管理SAP CAPアプリケーションのサービス定義とロールの設定SAP Cloud Identity Services – Identity Authenticationのユーザーグループによる権限管理 1. SAP Cloud Identity Services とは？SAP Cloud Identity Servicesは、SAP BTP上で提供されるクラウドベースのセキュリティサービス群であり、企業がアイデンティティとアクセス管理を効果的に行えるよう支援します。主に以下の特徴と構成要素から成り立っています。特徴中央集権管理：ユーザーのアイデンティティとアクセス権限を一元的に管理できます。これにより、セキュリティポリシーの一貫性が保たれ、管理作業が効率化されます。多様な認証オプション：多因子認証やリスクベースの認証など、様々な認証方法をサポートしています。これにより、セキュリティを強化しつつ、ユーザーフレンドリーなアクセスが可能です。クロスプラットフォーム対応：SAPの製品だけでなく、他の多くのクラウドサービスやオンプレミスのシステムとも統合可能です。これにより、広範囲のアプリケーションとサービスにわたって安全なアクセスが保証されます。槇成要素Identity Authentication Service (IAS)：認証サービスで、ユーザーのアイデンティティを確認し、セキュアな認証プロセスを提供します。ログイン試行時のユーザー検証や、認証データの保護などが行われます。Identity Provisioning Service (IPS)：アイデンティティプロビジョニングサービスで、ユーザーアカウントの作成、更新、削除などを自動化します。システム間でのアイデンティティ情報の同期も行うため、ユーザー管理がスムーズに実行されます。これらの特徴と構成要素を通じて、SAP Cloud Identity Servicesは企業のデジタル変革を安全かつスムーズに支援します。 2. SAP CAPアプリケーションにおける権限管理Web アプリケーションにおける認証は、アプリケーションのセキュリティを担保するために必要不可欠です。認証プロセスでは、ユーザーの身元を確認し、リクエストの正当性（例えば、ロールやテナントのメンバーシップ）を検証します。SAP CAPでは、この認証方法は多岐にわたってカスタマイズ可能であり、一般的なシナリオをカバーする標準的な認証方法がサポートされています。例えば、SAP BTP上で提供されているXSUAA（XS User Authentication and Authorization）サービス はOAuth 2.0に準拠した認証サーバーで、JWTトークンを通じてユーザー情報と認証情報を提供します。https://cap.cloud.sap/docs/guides/security/authorization中でも今回は、SAP CAPアプリケーションの認証実装でよく用いられるこのXSUAA形式での認証を前提にご紹介いたします。どの認証方式を利用するのか、という設定はpackage.jsonにて行います。 cds -> requires -> auth の値をxsuaa として設定を行なっておく必要があります。この辺りの詳しい説明は上記公式ドキュメントをご参照ください。package.json “cds”: {
“requires”: {
“[production]”: {
“db”: “hana”,
“auth”: “xsuaa”
},
“app-service”: {
“impl”: “@sap/low-code-event-handler”
},
“auth”: {
“[development]”: {
“kind”: “dummy”
},
“[production]”: {
“kind”: “xsuaa”
}
}
},
“features”: {
“fetch_csrf”: true
}
},  3. SAP CAPアプリケーションのサービス定義とロールの設定SAP CAPアプリケーションでは、一般に db/schema.cds で定義したデータモデルに対して、ODataサービスを定義して外部に公開します。この作業はsrv/service.cdsで行われ、下記のコードスニペットのように定義が行われます。(ファイル名は文脈に応じて変わる可能性もあります)service.cds using { cakeshop as my } from ‘../db/schema.cds’;

@path : ‘/service/cakeshop’
service cakeshopSrv
{
annotate Cake with @restrict :
[
{ grant : [ ‘*’ ], to : [ ‘store-manager’ ] },
{ grant : [ ‘*’ ], to : [ ‘store-staff’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-supervisor’ ] }
];

annotate Category with @restrict :
[
{ grant : [ ‘*’ ], to : [ ‘store-manager’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-staff’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-supervisor’ ] }
];

annotate Order with @restrict :
[
{ grant : [ ‘*’ ], to : [ ‘store-manager’ ] },
{ grant : [ ‘*’ ], to : [ ‘store-staff’ ] },
{ grant : [ ‘READ’ ], to : [ ‘store-supervisor’ ] }
];

@odata.draft.enabled
entity Cake as
projection on my.Cake;

@odata.draft.enabled
entity Category as
projection on my.Category;

@odata.draft.enabled
entity Order as
projection on my.Order;
}

annotate cakeshopSrv with @requires :
[
‘authenticated-user’,
‘store-manager’,
‘store-staff’,
‘store-supervisor’
]; このファイルでは、定義されたデータモデルを読み込み、それぞれのデータモデルを単一のODataサービス内のEntityとして公開しています。今回はケーキの在庫や注文を管理するという例になっています。この際 @restrict アノテーションを通じて、各EntityやODataサービス自体に対してCRUD操作の制限をかけることが可能です。今回は 以下のように分割された操作権限が定義されています。 ロール名対象エンティティと権限  CakeCategoryOrderauthenticated-user認証されたユーザー全般—store-manager店舗マネージャCRUDCRUDCRUDstore-staff店舗スタッフCRUDRCRUDstore-supervisorエリアマネージャRRRこの定義を行ったのち、ターミナルにて以下のコマンドを実行すると、これに基づいてロールの定義（xs-security.json）が生成されます。 cds compile srv/ –to xsuaa > xs-security.json xs-security.json {
“scopes”: [
{
“name”: “$XSAPPNAME.store-manager”,
“description”: “store-manager”
},
{
“name”: “$XSAPPNAME.store-staff”,
“description”: “store-staff”
},
{
“name”: “$XSAPPNAME.store-supervisor”,
“description”: “store-supervisor”
}
],
“attributes”: [],
“role-templates”: [
{
“name”: “store-manager”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.store-manager”
],
“attribute-references”: []
},
{
“name”: “store-staff”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.store-staff”
],
“attribute-references”: []
},
{
“name”: “store-supervisor”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.store-supervisor”
],
“attribute-references”: []
}
]
} これにより、このアプリケーションのデプロイと同時にロールがSAP BTP Cockpit上から利用できるようになります。 4. SAP Cloud Identity Services – Identity Authenticationのユーザーグループによる権限管理無事にSAP CAPアプリケーションのデプロイが完了すると、下図のように、アプリケーションに紐づいたロールがデプロイされます。SAP BTP上では、このロール群をまとめたロールコレクションという単位で権限の制御を行うため、まずはこのロールコレクションの作成を行います。今回は、それぞれのロールに対して1つのロールコレクションを作成しました。必要があれば、一つのロールコレクションに複数のロールを割り当てることも可能です。それでは最後に、このロールコレクションをSAP Cloud Identity Services – Identity Authenticationのユーザーグループに紐づけていきます。セキュリティ -> 認証設定から、SAP BTPを利用する際の認証に関する設定を行うことができます。今回はすでにSAP Cloud Identity Services – Identity Authenticationテナントの紐付けが済んでいるため、Custom IAS tenantの設定画面に入ります。ロールコレクションマッピングの設定にて、先程作成したロールコレクションと、SAP Cloud Identity Services – Identity Authenticationにおけるユーザーグループを対応させます。SAP BTP Cockpit側で行う作業は以上です。次に、SAP Cloud Identity Services – Identity Authenticationの管理者画面側で、ユーザーグループの作成とユーザーの割り当てを行います。まずは全てのEntityに対してRead権限のみを持つstore-supervisorにユーザーを割り当てます。この状態でアプリケーションにアクセスすると、以下のような画面になります。store-supervisor ロールを持つユーザーはCake Entity に対してCreate権限を持たないため、「作成」ボタンをクリックすると、Forbiddenが返ります。そこで、SAP Cloud Identity Services – Identity Authentication の管理者画面から、ユーザーのロールをstore-managerに変更します。すると、store-managerロールはCake Entityに対するCreate権限を持つため、「作成」ボタンをクリックするとエラーなく作成ページを開くことができるようになります。 まとめ本ブログでは SAP CAPカスタムアプリケーションにおけるアクセス権限の管理について、SAP Cloud Identity Servicesを使用する方法を解説しました。具体的には、SAP Cloud Identity Servicesの特徴や構成要素の説明、SAP CAPアプリケーションでの認証方法の設定、サービス定義とロールの定義方法、そして最終的にIdentity Authenticationのユーザーグループを通じた権限管理のプロセスをご紹介しました。今回のブログには含まれていませんが、SAP Cloud Identity Services – Identity Provisioningを組み合わせると、SCIMプロトコルに従ってユーザーやユーザーグループをSAP Cloud Identity Services – Identity Authenticationに連携し、他システムで管理されているユーザーに対しても、間接的に権限管理を行うことが可能です。SAP BTPにおけるSide-by-Side開発とは切っても切り離せない関係性のSAP Cloud Identity Servicesですが、このブログを足がかりにして、ぜひより深く学んでみてください。   Read More Technology Blogs by SAP articles 

#SAP

#SAPTechnologyblog