Access roles まとめ #17
Labels
bug
Something isn't working
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ロールの権限調査
■ 調査対象ソース
sw360-13.4.0-M1
(/datahandler/src/main/java/org/eclipse/sw360/datahandler/permissionsはsw360-14.0.0-M1と同等)
■ Liferayで設定するユーザのロール
REGULAR ROLE
ORGANIZATION ROLE
SITE ROLE
■ Liferayのロール管理
Liferayで選択できるロールは_roleテーブルで管理されている。
type_列の値でロールへ種別を設定している。
■ Role管理
Liferayユーザロールの読み替え
UserUtils.java
/sw360-portlet/src/main/java/org/eclipse/sw360/portal/users/UserUtils.java
getUserGroupFromLiferayUserメソッド
Liferayのユーザ情報からロール名を取得し、下記の文字列でマッチングして最初にマッチしたロールを付与する。
マッチングするLiferay側のロール情報は、SITE ROLESだけでなく、REGULAR ROLESも対象となる。REGULAR ROLESでAdministratorを選択すると、SW360側でADMIN権限が付与される。（SITE ROLEにはAdministrotorは選択肢に出てこない。）
この処理はLogin処理やUserPortletからも呼び出される共通処理。
→ Liferay側のロール定義に関わらず、上記の7つがSW360がサポートするロールである。
■ 権限制御
この項目では、SW360で扱う各種ロールについて、org.eclipse.sw360.datahandler.permissionsパッケージのクラスの制御を基に、アクセス可否の判定についてまとめる。下記の何れかのロールで条件が合えば、リソースに対してアクセス可能と判断する。
ただし、SW360ではpermissionsパッケージのクラスの利用は強制ではないため、
これらのクラスを参照しない業務ロジックについては、個別に権限制御を調べる必要がある。
Project
概要
Projectに対するアクセス許可は以下の記号で示す。
P(P) : Project(Private)
P(M) : Project(Me and Moderators)
P(B) : Project(Businessunit and moderators)
P(E) : Project(Everyone)
P : ProjectのVisibility設定に関わらずアクセス可能
プライマリロールによるアクセス制御
Projectと同一組織となることでアクセス可能となるケースは、後述の「リソースごとの役割の違いによるアクセス制御」へ情報をまとめる。
※ 権限テーブル上はADMINとSW360ADMINに区別はない
セカンダリのロールによるアクセス制御
セカンダリロールはProjectの所属組織に対応するユーザのロールが判定されるため、所属組織が異なるケースは扱わない。
※1 ProjectのREAD権限の判定のおいて、セカンダリのロールを基に権限をあたら得るような処理は見当たらなかった。ProjectのVisibilityがBUISNESSUNIT_AND_MODERATORSの場合、ユーザが所属するセカンダリグループの所属組織は判定するものの、セカンダリのロールは考慮しない。（本表では、セカンダリグループの一致は、Same group userとして扱う。）
なお、READ権限以外は、isUserOfOwnGroupHasRoleによりセカンダリグループも含めた、Projectの所属組織にマッチする組織のロールについて、権限判定を行っている。
リソースごとの役割の違いによるアクセス制御
※Same group user、Other group userはセカンダリの所属組織を含む。
Project(Closed)
概要
P(P) : Project(Private)
P(M) : Project(Me and Moderators)
P(B) : Project(Businessunit and moderators)
P(E) : Project(Everyone)
P : ProjectのVisibility設定に関わらずアクセス可能
プライマリロールによるアクセス制御 （ProjectとUserのプライマリの所属組織が同一の場合）
Projectと同一組織となることでアクセス可能となるケースは、後述の「リソースごとの役割の違いによるアクセス制御」へ情報をまとめる。
READ権限の処理は、プロジェクトのClosed状態の影響を受けない。
プライマリロールによるアクセス制御 （ProjectとUserのプライマリの所属組織が異なる場合）
READ権限の処理は、プロジェクトのClosed状態の影響を受けない。
セカンダリのロールによるアクセス制御
セカンダリロールはProjectの所属組織に対応するユーザのロールが判定されるため、所属組織が異なるケースは扱わない。
READ権限の処理は、プロジェクトのClosed状態の影響を受けない。
リソースごとの役割の違いによるアクセス制御
※Same group user、Other group userはセカンダリの所属組織を含む。
READ権限の処理は、プロジェクトのClosed状態の影響を受けない。
バックエンド処理におけるModerators、Contributorsについて（補足）
上記のModerators、Contributorsは、画面上でモデレータやコントリビュータとして登録されたユーザではなく、権限処理において、Moderators、およびContributorsとして扱われるユーザ。
Moderatorsとして判定するユーザ
Contributorsとして判定するユーザ
Component
概要
Component閲覧制限の改造を含まない、Githubメインソースにおける制御についてまとめる。
Componentに対するアクセス許可は以下の記号で示す。
C : コンポーネント
ロール（プライマリ／セカンダリ共通）によるアクセス制御
※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。
リソースごとの役割の違いによるアクセス制御
Componentにはグループを対象とした制御は存在しない。
Componentに対して、Component Ownerというユーザを登録できるが、特別な権限を与えるような処理は見当
たらなかった。
バックエンド処理におけるModerators、Contributorsについて（補足）
Moderatorsとして判定するユーザ
Contributorsとして判定するユーザ
ComponentにはContributorというユーザは設定できないが、バックエンド側ではModeratorと同じユーザをContributorとして扱っている。
Release
概要
Component閲覧制限の改造を含まない、Githubメインソースにおける制御についてまとめる。
Relaseに対するアクセス許可は以下の記号で示す。
R : リリース
ロール（プライマリ／セカンダリ共通）によるアクセス制御
※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。
リソースごとの役割の違いによるアクセス制御
Releaseにはグループを対象とした制御は存在しない。
バックエンド処理におけるModerators、Contributorsについて（補足）
Moderatorsとして判定するユーザ
Contributorsとして判定するユーザ
License
概要
Licenseに対するアクセス許可は以下の記号で示す。
L : ライセンス
プライマリロールによるアクセス制御
セカンダリロールによるアクセス制御
LicensePermissionsはUserのセカンダリのロールを考慮しない。
Licenseにはリソースごとの役割の違いによるアクセス制御は存在しない。
このため、Creatorであっても特別な権限は付与されない。（作成者であってもCLEARING ADMIN以上の権限が無ければLicenseを削除することはできない。）
Vendor
概要
Vendorに対するアクセス許可は以下の記号で示す。
V : ベンダー
ロール（プライマリ／セカンダリ共通）によるアクセス制御
※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。
Vendor固有の制御は行っておらず、DocumentPermissionsの制御に従う。
Vendorにはリソースごとの役割の違いによるアクセス制御は存在しない。
このため、Creatorであっても特別な権限は付与されない。
User
概要
Userに対するアクセス許可は以下の記号で示す。
U : User
プライマリロールによるアクセス制御
セカンダリロールによるアクセス制御
UserPermissionsはUserのセカンダリのロールを考慮しない。
Userにはリソースごとの役割の違いによるアクセス制御は存在しない。
このため、Creatorであっても特別な権限は付与されない。
Vulnerability
概要
Vulnerabilityに対するアクセス許可は以下の記号で示す。
V : 脆弱性
ロール（プライマリ／セカンダリ共通）によるアクセス制御
※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。
Vulnerability固有の制御は行っておらず、DocumentPermissionsの制御に従う。
Vulnerabilityにはリソースごとの役割の違いによるアクセス制御は存在しない。
このため、Creatorであっても特別な権限は付与されない。
The text was updated successfully, but these errors were encountered: