YIIおよびLDAPのRBAC許可

RBACは、Webアプリケーションへのアクセスを集中管理するためのシンプルで強力な方法です。 主な利点は、承認階層を正しく理解して適用することで、コントローラーのコードを変更せずに非常に柔軟にアクセスを制御できることです。



残念ながら、YIIの標準RBACマニュアルには回答よりも多くの質問が残されています。 この状況を修正するつもりです。

「正しい」階層の作成について説明します。その方法は価値がありません。 そして最後に、LDAP承認（ActiveDirectoryから）をYiiとRBACと友達にする方法に関する指示を保存しました。



興味のある方、猫へようこそ！





RBAC （役割ベースのアクセス制御）役割ベースのアクセス制御 。 Yiiのこのシステムの基本は、3つの主要なリンクです：

• 役割
• タスク
• 操作（操作）

読者はすでに公式のYII教科書のページを簡単にレビューしており、Yiiの認可メカニズムの基本原則を知っていると思います。



したがって、承認要素の正しい階層の構築にすぐに進みます。

ロールの階層。

最も重要で理解しにくいのは、RBACの要素の階層です。 それがどれほどよく考えられているかは、システム内のロールをどれだけ柔軟に管理できるか、およびコントローラーコードを変更する必要がある頻度によって異なります。



各承認要素についてさらに詳しく考えてみましょう。

• 操作は、承認の最も低い要素です。 これは、コントローラーのコードで確認する必要があるものです。 言い換えれば、操作はコードにしがみつくものです。
• 反対に、 役割は、操作とタスクをグループ化する承認の最高の要素です。 そして、それがユーザーにアタッチしなければならない役割です。
• タスク -これは、操作とロールの間のオプション要素であり、bizRuleを使用して操作の権限を制限します。 理解を容易にするために、 フィルターと呼びましょう。

上の図は、コントローラーが操作をチェックし、ロールがユーザーに割り当てられている一般的な階層を示しています。 ただし、YIIは、ユーザーロールなど、コントローラー内の他のものをチェックすることを妨げません。

ただし、これは誤りであり、集中管理の利点を失うという事実につながることを覚えておく必要があります。



例を考えてみましょう：

私たちは、管理者に対してアクセスを差別化したいニュースを持っています。

RBACを設計する際に最初にすべきことは、可能な操作（一見するとユーザーロールではなく）を検討することです。



通常、ニュースは削除 、 作成 、 読み取り 、 編集できます。 これらのアクションをdeleteNews 、 createNews 、 readNews 、 updateNewsの オペレーションに変換します。



コードでは、次の操作のいずれかを確認できます。

if(Yii::app()->user->checkAccess('createNews')) { //   } // if(Yii::app()->user->checkAccess('updateNews')) { //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

操作が検討された後、ロールに進むことができます（タスクを意図的にスキップします。それらについては少し後で説明します）。



利用可能な操作から、次の役割を区別できます。

newsReader 、 newsManager 、 newsAuthor 。



要素の階層は次のとおりです。

• newsReader
  • readNews
• ニュース
  • readNews
  • createNews
• newsManager
  • readNews
  • createNews
  • deleteNews
  • updateNews

これらのロールは、特定のユーザーに関連付けることができます。 しかし、より一般化された役割の別の抽象化を作成し、それをユーザーに添付する方が良いでしょう、例えば：

• ゲスト
  • newsReader
• 認可された
  • ニュース
• モデレーター
  • newsManager

このような抽象化は、ニュースだけでなく、フォトギャラリーの写真や店内の商品も管理する必要がある場合に便利です。 次に、システムのこのようなセクションごとに、 photoReader（showPhoto） 、 photographer（showPhoto 、 addPhoto ） 、 photoManager（showPhoto、addPhoto、deletePhoto）などの独自の「中間」ロールを作成し、一般化されたロールにアタッチする必要があります。

• ゲスト
  • newsReader
  • フォトリーダー
• 認可された
  • ニュース
  • 写真家
• モデレーター
  • newsManager
  • photoManager

つまり ゲストはニュースを読み、写真を見ることができます。 承認されたユーザーは、ニュースを書いて写真を追加できます。 モデレーターは上記のすべてを実行できるだけでなく、他の人の写真やニュースを編集および削除できます。



おそらく、更新操作はnewsAuthorロールとPhotographerロールでは使用できないことに気づいたでしょう。 そうです、この段階でupdateNewsまたはupdatePhotoの操作を与えると、すべての写真を無差別に管理できるようになるからです。 そして、著者は自分の要素のみを編集できる必要があります。



このためにタスクが作成されます。 タスクは、権限を指定できるフィルターです。 updateOwnNewsタスクを作成しましょう。 このタスクの子孫はupdateNewsを割り当てます 。 タスクの名前から、それはあなたがあなた自身のニュースを編集することを可能にすることは明らかであり、bizRuleはこれで私たちを助けます。



bizRuleはある種のPHPコードであり、その結果が答えです。このユーザーにこのルールを適用するかどうかです。



updateOwnNewsタスクのbizRuleは次のようになります。

 $bizRule='return Yii::app()->user->id==$params["news"]->authID;';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作成者のIDが現在の承認済みユーザーのニュースと一致するかどうかを確認します。



ビジネスルールで現在のニュースアイテムを取得するには、まずそこに渡す必要があります。

 $params=array('news'=>$post); if(Yii::app()->user->checkAccess('updateNews',$params)) { //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特定のタスク（ updateOwnNews ）ではなく、 updateNews操作（階層の最下位要素）をチェックしていることに注意してください。



タスクの作成後にupdateOwnNewsが次のようになった階層のおかげです。

• ニュース
  • readNews
  • createNews
  • updateOwnNews
    • updateNews

Yiiは下からアクセス制御を開始し、階層を上に移動します。 updateNewsを確認し、updateOwnNewsに移動します。 チェックの各段階で、Yiiはチェックします。bizRuleルールが設定されている場合、設定されている場合、checkAccess関数で指定されたパラメーターを渡します。



チェックは、次のように概略的に表すことができます。







この図は、3つのテストシナリオを示しています。

最初のシナリオは、承認されたユーザーが自分のニュースを編集しようとした場合です。 この場合、下から上へのチェックはupdateOwnNewsを通過します 。 また、ユーザーIDは同じであるため、成功します。



2番目のケースでは、ユーザーはモデレーターの役割を持っています。 階層にはupdateOwnNewsタスクがないため、updateNews操作の存在のみがチェックされます。

検証に成功しました。



3番目のケースでは、許可されたユーザーが他の人の記事を編集しようとしますが、 updateOwnNewsステージではチェックが失敗します。 満たされていないbizRuleタスク。



上記の例は、集中管理された権利管理を示しています。

操作を完了するためにコントローラーに1回チェックを書き込み、そこでパラメーターを渡すことにより、アクセス制御に関する以降の作業はすべてRBACに任されます。

したがって、可能な場合は常に 、checkAccess関数にパラメーターを渡して（チェック対象のアイテムにbizRuleがない場合でも）、ロールではなく操作をチェックする必要があります。



コントローラー内で1つの条件で複数のチェックを作成する場合-間違った方向に進んでいることがわかっている-階層の編成に問題がある場合。



例：

 if(Yii:app()->user->checkAccess('moderator') && Yii:app()->user->checkAccess('administrator')) { //delete smth }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは間違っています。 このアプローチでは、権限を一元管理できません。 毎回コードを編集し、ここに新しい条件を追加する必要があります。

コントローラーの権限を確認する方法

権利を確認するには2つの方法があります。

すでに検討した最初の方法。 これは、 CWebUserコンポーネントのcheckAccess（）メソッドです。



しかし、自分のコントローラーが「太っていない」ことを気にする人には、権利をチェックする別のアスペクト指向の方法があります。



この方法は、「accessControl」フィルターをコントローラーに接続することです。



このフィルターはすべての汚れた作業を行います。アクセス権を確認し、必要に応じてユーザーをページ403に送信します。したがって、各アクションで検証コードを複製する必要はありません。



ニュースコントローラーの例によるフィルターを検討してください。

 class NewsController extends CController { … public function filters() { return array( 'accessControl', ); } public function accessRules() { return array( array('allow', 'actions'=>array('create'), 'roles'=>array('createNews'), ), array('allow', 'actions'=>array('delete'), 'roles'=>array('deleteNews'), ), array('allow', 'actions'=>array('view'), 'roles'=>array('readNews'), ), array('allow', 'actions'=>array('update'), 'roles'=>array('updateNews'), ), ); } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

accessRules関数では、4つのルールを指定します。各ルールは配列です。 アクションキーがルールを適用するアクションとロールのキーを示す場所。



キーが「ロール」と呼ばれるという事実にもかかわらず、操作またはタスクであるかに関係なく、そこに任意の許可要素を入力できることに注意する必要があります。 しかし、ご存知のように、コントローラーでは操作のみをチェックする必要があるため、上記の例に記載されているのはそのためです。



このフィルターは、アクションの「パススルー」コードの多くの行を取り除くのに役立ちます。 ただし、問題があります。updateOwnNewsで定義されたbizRuleが正しく機能するように、「updateNews」で現在のニュースを送信する必要があります。



パラメーターをフィルターに渡す方法を理解するために、フレームワークコードを取得し、そこを覗く必要がありました。 幸いなことに、バージョン1.1.11からこのような機会が現れました。



パラメータを渡すには、次のようなルールを記述する必要があります。

 'roles'=>array('newsUpdate'=>array('news'=>$news))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、問題はそれだけでは終わりません。 フィルタは、アクションの前に実行されます。つまり、送信できるニュースオブジェクトをまだ作成していないことを意味します。



解決策は次のアプローチです。

 protected $model; public function accessRules() { return array( ... array('allow', 'actions' => array('update'), 'roles' => array( 'updateNews' => array( 'news' => $this->news )), ), ... ); } public function getNews() { if ($this->actionParams['id']) { return $this->loadModel($this->actionParams['id']); } } public function loadModel($id) { if ($this->model === null) $this->model = News::model()->findByPk($id); if ($this->model === null) throw new CHttpException(404, 'The requested page does not exist.'); return $this->model; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、loadModel関数を使用して、ニュースモデル用のニュースフィールドのゲッターを作成します。 しかし、データベースを数回プルしないように（権限をチェックする最初とアクション自体で）、モデルがキャッシュされるプライベートフィールド$モデルを作成しました。次にloadModel関数にアクセスすると、プロパティからモデルが取得されます。ベースからではありません。



残念ながら、原則として、より複雑なロジックを必要とするパラメーターを送信する必要がある場合、この方法は適していません。 したがって、このような場合、checkAccess（）を使用することは残ります。

RBAC YiiおよびLDAP

LDAPは、軽量ディレクトリアクセスプロトコルであり、「軽量ディレクトリアクセスプロトコル」です。 この場合、ユーザー名とパスワードを使用して企業ネットワークからユーザーを認証するために、ActiveDirectoryディレクトリにアクセスします。



PHPにはLDAPサポートが組み込まれているため、何も発明する必要はありません。また、ディレクトリにアクセスするための便利なインターフェイスを提供する既製のコンポーネントが多数あります。



adLdapコンポーネントを使用しました。 ActiveDirectory用に特別に設計されており、シンプルで便利なOOP APIを提供します。また、それを使用するのは素晴らしいことです。



始めるために、adLdapをアプリケーションコンポーネントとしてYiiに接続しました。

 //protected/config/main.php 'components' => array( ... 'ldap' => array( 'class' => 'LdapComponent', 'baseDn' => 'DC=example,DC=org', //example.org 'accountSuffix' => '@example.org', 'domainControllers' => array('dc.example.org'), 'adminUsername' => 'username', 'adminPassword' => 'password' ), .. )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LdapComponentクラス自体：

 //protected/components/LdapComponent.php Yii::import('application.vendors.adLDAP.adLDAP'); class LdapComponent extends adLDAP { public $baseDn; public $accountSuffix; public $domainControllers; public $adminUsername; public $adminPassword; public function __construct() { } public function init() { parent::__construct(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AdLdapは、そのプロパティをオーバーライドすることにより構成されます。 Yiiプログラマーに馴染みのある形式でconfigのこのコンポーネントの設定を行いたいので、可視属性を変更して（Yiiがコンポーネントを構成できるように）必要なフィールドを再定義し、コンストラクターをinit（）メソッドに転送してコンストラクターがAFTERと呼ばれるようにしましたオブジェクトが構成されます（フィールドがいっぱいになります）。



さらに、このコンポーネントをYiiの他のすべてのコンポーネントと同じように使用できます。

 Yii::app()->ldap
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LDAPを使用した認可の場合、Yiiで認可に必要な標準コンポーネントUserIdentityおよびWebUserを作成する必要があります。

 //protected/components/LdapIdentity.php class LdapIdentity extends CUserIdentity { protected $_id; /** * Authenticates a user via LDAP. * @return boolean whether authentication succeeds. */ public function authenticate() { $ldap = Yii::app()->ldap; $result = $ldap->authenticate($this->username, $this->password); $ldapUserInfo = $ldap->user()->infoCollection($this->username, array("mail", "displayname")); $this->setState('fullname', $ldapUserInfo->displayname); $this->setState('email', $ldapUserInfo->mail); if (!$result) { $this->errorCode = self::ERROR_USERNAME_INVALID; } else { $dbUser = User::model()->findByAttributes(array('ldap' => $this->username)); if (!$dbUser) { $dbUser = new User(); $dbUser->ldap = $this->username; $dbUser->save(); } $this->_id = $dbUser->primaryKey; $this->errorCode = self::ERROR_NONE; } return !$this->errorCode; } public function getId() { return $this->_id; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコードでは、承認ロジックを実装するために、CUserIdentityクラスの認証メソッドを再定義しています。 adLdapを介してADでこのユーザーを認証しようとしています。成功した場合は、ユーザーの名前とメールを永続的なストレージに格納します。



LDAPに加えて、ユーザーに関する追加情報をデータベースに保存することにしました。そのため、認証に成功した後、チェックされます。このユーザーのデータベースにすでに行があり、そうでない場合は作成されます。

 //protected/components/LdapUser.php class LdapUser extends CWebUser { protected $_groups = null; protected $_model; /** * * @return type */ public function getGroups() { if ($this->_groups === null) { if ($user = $this->getModel()) { $this->_groups = Yii::app()->ldap->user()->groups($user->ldap); } } return $this->_groups; } /** * * @return User */ public function getModel() { if (!$this->isGuest && $this->_model === null) { $this->_model = User::model()->findByPk($this->id); } return $this->_model; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LdapUserクラスは、重要な機能であるLdapUser :: getGroups（）を除いて、標準とほとんど変わりません。 ご想像のとおり、この関数はADからこのユーザーのすべてのグループを返します。



YiiアプリケーションのActiveDirectoryロールでユーザーグループを作成することにしました。

つまり 特定のユーザーではなくグループにロールを割り当てます。 そして、どのグループがADを通じて一元的に誰に割り当てられます。

企業ポータルや他の内部リソースでは非常に便利です。 プリンター、フォルダー、およびその他のオフィスインフラストラクチャに対する権限と共に、ユーザーには企業Webサイトのセクションに対する権限が直ちに付与されます。 同時に、IT部門のスペシャリストは何も説明する必要はなく、「いつものように」作業を行うだけです。



ユーザーにロールを割り当てるために、CPhpAuthManagerクラスを再定義しました。

 class PhpAuthManager extends CPhpAuthManager { public function init() { //      auth.php   config  if ($this->authFile === null) { $this->authFile = Yii::getPathOfAlias('application.config.auth') . '.php'; } parent::init(); //          guest. if (!Yii::app()->user->isGuest) { //    AD     $existingRoles = $this->getRoles(); if (Yii::app()->user->groups) { foreach (Yii::app()->user->groups as $group) { if ($existingRoles[$group]) { $this->assign($group, Yii::app()->user->id); } } } } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコードでは、ユーザーが属するグループのリストを取得し、同じ名前のロールが存在するかどうかを確認します。存在する場合は、ユーザーにロールを割り当てます。



LDAPを使用した許可構成ファイルの例は次のようになります。

  ... /************************************ ***************ROLES**************** ************************************/ 'newsReader' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 0 => 'readNews', ), ), 'newsAuthor' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'newsReader', 'createNews', 'updateOwnNews', 'deleteOwnNews' ), ), 'newsManager' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'newsReader', 'createNews', 'updateNews', 'deleteNews', ), ), // 'requestCreator' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 0 => 'createRequest', ), ), 'requestManager' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'createRequest', 'viewRequests', 'manageRequests', ), ), /************************************ **********ROLES ASSIGMENTS********** ************************************/ 'developers' => array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'newsManager', 'requestManager', ), ), 'departamentBoss'=> array( 'type' => CAuthItem::TYPE_ROLE, 'description' => '', 'bizRule' => NULL, 'data' => NULL, 'children' => array( 'requestCreator' , ), ),
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ROLESセクションでは、「中間」ロールについて説明します。 次に、「役割の割り当て」セクションで、ADのグループについて説明し、それらに中間の役割を割り当てます。



上記の設定は次のように読むことができます：

開発者グループの場合、ニュース（newsManager）およびアプリケーション（requestManager）を含むすべてのアクションが使用可能になり、 departamentBossグループの場合、アプリケーションの作成のみが使用可能になります。

おわりに

Yiiのロールメカニズムは、適切に使用すれば本当に柔軟です。

将来の計画には、GUIロール管理ソリューションの作成または適応が含まれます。 少数のアクションでも、システムは混乱し、書き込みの量は不当になります。

すべてのユーザーに、Yiiプロジェクトで権利管理システムをどのように実装したか、そして個人的な経験から得たどのようなヒントが他の人に役立つかを議論することをお勧めします。

他に読むもの：

• Yii公式ガイド
• 権利の階層+他の人の経験がどのように機能するかについての良い記事
• フォーラムでの議論から、一度は多くの有用なことを学びました（クレオコーダーの投稿を読んでください）
• ウィキペディアのLDAP
• AdLdapガイド