KoukiHama/sw360

Access roles まとめ

KoukiHama opened this issue · 0 comments

KoukiHama commented

ロールの権限調査

■ 調査対象ソース

sw360-13.4.0-M1
(/datahandler/src/main/java/org/eclipse/sw360/datahandler/permissionsはsw360-14.0.0-M1と同等)

■ Liferayで設定するユーザのロール

  • REGULAR ROLE

    ロール名
    Administrator
    Analytics Administrator
    Portal Content Reviewer
    Power User

  • ORGANIZATION ROLE

    ロール名
    Account Manager
    Organization Administrator
    Organization Content Reviewer
    Organization Owner

  • SITE ROLE

    ロール名
    Clearing Admin
    Clearing Expert
    ECC Admin
    Security Admin
    Site Aministrator
    Site Conternt Reviewer
    Site Owner
    SW360 Admin

■ Liferayのロール管理

  • _roleテーブル
    Liferayで選択できるロールは_roleテーブルで管理されている。
    type_列の値でロールへ種別を設定している。
    ロール種別 type_ 補足
    REGULAR ROLE 1 Guest,Owner, Power User Userはtype=1のロールとして定義されているが表示されない。
    SITE ROLE 2
    ORGANIZATION ROLE 3 Organization Userはtype=3のロールとして定義されているが表示されない。

■ Role管理

  • Liferayユーザロールの読み替え

    • UserUtils.java
      /sw360-portlet/src/main/java/org/eclipse/sw360/portal/users/UserUtils.java
      getUserGroupFromLiferayUserメソッド

    • Liferayのユーザ情報からロール名を取得し、下記の文字列でマッチングして最初にマッチしたロールを付与する。

    マッチング順序 定数名 Liferayのロール名 SW360で割り当てるロール
    1 ROLENAME_ADMIN "Administrator" ADMIN
    2 ROLENAME_SW360_ADMIN "SW360 Admin" SW360_ADMIN
    3 ROLENAME_CLEARING_EXPERT "Clearing Expert" CLEARING_EXPERT
    4 ROLENAME_CLEARING_ADMIN "Clearing Admin" CLEARING_ADMIN
    5 ROLENAME_ECC_ADMIN "ECC Admin" ECC_ADMIN
    6 ROLENAME_SECURITY_ADMIN "Security Admin" SECURITY_ADMIN
    7 上記のロール名に該当しない場合 - USER

    • マッチングする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 SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ P(B),P(E) P(B),P(E) P(B),P(E) P(B),P(E) P(E) P(E) P(E)
    WRITE P P P P - - -
    DELETE P P - - - - -
    USERS P P - - - - -
    CLEARING P P - - - - -
    ATTACHMENTS P P P P - - -
    WRITE_ECC P P - - - - -

    ※ 権限テーブル上はADMINとSW360ADMINに区別はない


  • セカンダリのロールによるアクセス制御
    セカンダリロールはProjectの所属組織に対応するユーザのロールが判定されるため、所属組織が異なるケースは扱わない。

    セカンダリロール ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ ※1 - - - - - - -
    WRITE P P P P - - -
    DELETE P P - - - - -
    USERS P P - - - - -
    CLEARING P P - - - - -
    ATTACHMENTS P P P P - - -
    WRITE_ECC P P - - - - -

    ※1 ProjectのREAD権限の判定のおいて、セカンダリのロールを基に権限をあたら得るような処理は見当たらなかった。ProjectのVisibilityがBUISNESSUNIT_AND_MODERATORSの場合、ユーザが所属するセカンダリグループの所属組織は判定するものの、セカンダリのロールは考慮しない。（本表では、セカンダリグループの一致は、Same group userとして扱う。）
    なお、READ権限以外は、isUserOfOwnGroupHasRoleによりセカンダリグループも含めた、Projectの所属組織にマッチする組織のロールについて、権限判定を行っている。


  • リソースごとの役割の違いによるアクセス制御

    リソースロール Creator Architect Project responsible Moderators Contributors Same group user Other group user
    READ P P(M),P(B),P(E) P(M),P(B),P(E) P(M),P(B),P(E) P(M),P(B),P(E) P(B),P(E) P(E)
    WRITE P P P P P - -
    DELETE P - P P - - -
    USERS P - P P - - -
    CLEARING P - P P - - -
    ATTACHMENTS P P P P P - -
    WRITE_ECC - - - - - - -

    ※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と同一組織となることでアクセス可能となるケースは、後述の「リソースごとの役割の違いによるアクセス制御」へ情報をまとめる。

    プライマリロール ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ P(B),P(E) P(B),P(E) P(B),P(E) P(B),P(E) P(E) P(E) P(E)
    WRITE P P P P - - -
    DELETE P P - - - - -
    USERS P P - - - - -
    CLEARING P P - - - - -
    ATTACHMENTS P P P P - - -
    WRITE_ECC P P - - - - -

    READ権限の処理は、プロジェクトのClosed状態の影響を受けない。


  • プライマリロールによるアクセス制御 （ProjectとUserのプライマリの所属組織が異なる場合）

    プライマリロール ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ P(B),P(E) P(B),P(E) P(B),P(E) P(B),P(E) P(E) P(E) P(E)
    WRITE P P - - - - -
    DELETE P P - - - - -
    USERS P P - - - - -
    CLEARING P P - - - - -
    ATTACHMENTS P P - - - - -
    WRITE_ECC P P - - - - -

    READ権限の処理は、プロジェクトのClosed状態の影響を受けない。


  • セカンダリのロールによるアクセス制御
    セカンダリロールはProjectの所属組織に対応するユーザのロールが判定されるため、所属組織が異なるケースは扱わない。

    セカンダリロール ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ - - - - - - -
    WRITE P P P P - - -
    DELETE P P - - - - -
    USERS P P - - - - -
    CLEARING P P - - - - -
    ATTACHMENTS P P P P - - -
    WRITE_ECC P P - - - - -

    READ権限の処理は、プロジェクトのClosed状態の影響を受けない。


  • リソースごとの役割の違いによるアクセス制御

    リソースロール Creator Architect Project responsible Moderators Contributors Same group user ※ Other group user ※
    READ P P(M),P(B),P(E) P(M),P(B),P(E) P(M),P(B),P(E) P(M),P(B),P(E) P(B),P(E) P(E)
    WRITE - - - - - - -
    DELETE - - - - - - -
    USERS - - - - - - -
    CLEARING - - - - - - -
    ATTACHMENTS - - - - - - -
    WRITE_ECC - - - - - - -

    ※Same group user、Other group userはセカンダリの所属組織を含む。
    READ権限の処理は、プロジェクトのClosed状態の影響を受けない。


  • バックエンド処理におけるModerators、Contributorsについて（補足）
    上記のModerators、Contributorsは、画面上でモデレータやコントリビュータとして登録されたユーザではなく、権限処理において、Moderators、およびContributorsとして扱われるユーザ。

    • Moderatorsとして判定するユーザ

      • Creator
      • Project resposible
      • Moderator (モデレータ登録されているユーザ)

    • Contributorsとして判定するユーザ

      • Creator
      • Project resposible
      • Moderator (モデレータ登録されているユーザ)
      • Contributor (コントリビュータ登録されているユーザ)
      • Architect (リードアーキテクトとして登録されているユーザ)

Component

  • 概要
    Component閲覧制限の改造を含まない、Githubメインソースにおける制御についてまとめる。
    Componentに対するアクセス許可は以下の記号で示す。
    C : コンポーネント

  • ロール（プライマリ／セカンダリ共通）によるアクセス制御

    ロール ※ ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ C C C C C C C
    WRITE C C C C - - -
    DELETE C C - - - - -
    USERS C C - - - - -
    CLEARING C C - - - - -
    ATTACHMENTS C C C C - - -
    WRITE_ECC C C - - - - -

    ※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。


  • リソースごとの役割の違いによるアクセス制御

    リソースロール Creator Moderators Component Owner
    READ C C -
    WRITE C C -
    DELETE C C -
    USERS C C -
    CLEARING C C -
    ATTACHMENTS C C -
    WRITE_ECC - - -

    Componentにはグループを対象とした制御は存在しない。
    Componentに対して、Component Ownerというユーザを登録できるが、特別な権限を与えるような処理は見当
    たらなかった。

  • バックエンド処理におけるModerators、Contributorsについて（補足）

    • Moderatorsとして判定するユーザ

      • Creator
      • Moderator (モデレータ登録されているユーザ)

    • Contributorsとして判定するユーザ
      ComponentにはContributorというユーザは設定できないが、バックエンド側ではModeratorと同じユーザをContributorとして扱っている。

Release

  • 概要
    Component閲覧制限の改造を含まない、Githubメインソースにおける制御についてまとめる。
    Relaseに対するアクセス許可は以下の記号で示す。
    R : リリース

  • ロール（プライマリ／セカンダリ共通）によるアクセス制御

    ロール ※ ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ R R R R R R R
    WRITE R R R R - - -
    DELETE R R - - - - -
    USERS R R - - - - -
    CLEARING R R - - - - -
    ATTACHMENTS R R R R - - -
    WRITE_ECC R R - - R - -

    ※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。


  • リソースごとの役割の違いによるアクセス制御

    リソースロール Creator Moderators Contributors
    READ R R R
    WRITE R R R
    DELETE R R -
    USERS R R -
    CLEARING R R -
    ATTACHMENTS R R R
    WRITE_ECC - - -

    Releaseにはグループを対象とした制御は存在しない。

  • バックエンド処理におけるModerators、Contributorsについて（補足）

    • Moderatorsとして判定するユーザ

      • Creator
      • Moderator (モデレータ登録されているユーザ)

    • Contributorsとして判定するユーザ

      • Creator
      • Moderator (モデレータ登録されているユーザ)
      • Contributors (コントリビュータ登録されているユーザ)

License

  • 概要
    Licenseに対するアクセス許可は以下の記号で示す。
    L : ライセンス

  • プライマリロールによるアクセス制御

    ロール ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ L L L L L L L
    WRITE L L L L L L L
    DELETE L L L L - - -
    USERS - - - - - - -
    CLEARING L L L L - - -
    ATTACHMENTS - - - - - - -
    WRITE_ECC - - - - - - -

  • セカンダリロールによるアクセス制御
    LicensePermissionsはUserのセカンダリのロールを考慮しない。


  • リソースごとの役割の違いによるアクセス制御
    Licenseにはリソースごとの役割の違いによるアクセス制御は存在しない。
    このため、Creatorであっても特別な権限は付与されない。（作成者であってもCLEARING ADMIN以上の権限が無ければLicenseを削除することはできない。）

Vendor

  • 概要
    Vendorに対するアクセス許可は以下の記号で示す。
    V : ベンダー

  • ロール（プライマリ／セカンダリ共通）によるアクセス制御

    ロール ※ ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ V V V V V V V
    WRITE V V V V - - -
    DELETE V V - - - - -
    USERS V V - - - - -
    CLEARING V V - - - - -
    ATTACHMENTS V V V V - - -
    WRITE_ECC V V - - - - -

    ※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。
    Vendor固有の制御は行っておらず、DocumentPermissionsの制御に従う。


  • リソースごとの役割の違いによるアクセス制御
    Vendorにはリソースごとの役割の違いによるアクセス制御は存在しない。
    このため、Creatorであっても特別な権限は付与されない。

User

  • 概要
    Userに対するアクセス許可は以下の記号で示す。
    U : User

  • プライマリロールによるアクセス制御

    ロール ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ U U U U U U U
    WRITE U U - - - - -
    DELETE U U - - - - -
    USERS - - - - - - -
    CLEARING - - - - - - -
    ATTACHMENTS - - - - - - -
    WRITE_ECC - - - - - - -

  • セカンダリロールによるアクセス制御
    UserPermissionsはUserのセカンダリのロールを考慮しない。


  • リソースごとの役割の違いによるアクセス制御
    Userにはリソースごとの役割の違いによるアクセス制御は存在しない。
    このため、Creatorであっても特別な権限は付与されない。

Vulnerability

  • 概要
    Vulnerabilityに対するアクセス許可は以下の記号で示す。
    V : 脆弱性

  • ロール（プライマリ／セカンダリ共通）によるアクセス制御

    ロール ※ ADMIN SW360_ADMIN CLEARING_EXPERT CLEARING_ADMIN ECC_ADMIN SECURITY_ADMIN USER
    READ V V V V V V V
    WRITE V V V V - - -
    DELETE V V - - - - -
    USERS V V - - - - -
    CLEARING V V - - - - -
    ATTACHMENTS V V V V - - -
    WRITE_ECC V V - - - - -

    ※プライマリ、セカンダリのいづれかで必要なロールが設定されている場合はアクセスを許可する。
    Vulnerability固有の制御は行っておらず、DocumentPermissionsの制御に従う。


  • リソースごとの役割の違いによるアクセス制御
    Vulnerabilityにはリソースごとの役割の違いによるアクセス制御は存在しない。
    このため、Creatorであっても特別な権限は付与されない。