「対象」インタフェースにより、レルム内部で基本的なアイデンティティー管理を行うことができます。「対象」インタフェースで作成するすべてのアイデンティティーは、Access Manager アイデンティティー対象タイプを使って作成されるポリシーに対する対象定義で使用できます。
作成および変更できるアイデンティティーには、次のものがあります。
ユーザーは、個人のアイデンティティーを表現します。グループ内でユーザーを作成および削除できます。また、ロールやグループにユーザーを追加したり、ロールやグループからユーザーを削除することができます。サービスをユーザーに割り当てることもできます。
「ユーザー」タブをクリックします。
「新規」をクリックします。
次のフィールドのデータを入力します。
「ユーザー ID」: このフィールドには、ユーザーが Access Manager へログインするために使用する名前を指定します。このプロパティーは、DN 以外の値になることがあります。
「名」:このフィールドには、ユーザーの名 (ファーストネーム) を指定します。
「姓」: このフィールドはユーザーの姓 (ラストネーム) を取得します。
「フルネーム」: このフィールドには、ユーザーのフルネームを指定します。
「パスワード」: このフィールドには、「ユーザー ID」フィールドで指定した名前のパスワードを指定します。
「パスワード (確認)」: 確認のためにパスワードを再入力します。
「ユーザー状態」: このオプションは、Access Manager による認証をユーザーに許可するかどうかを指定します。
「作成」をクリックします。
ユーザーの作成後は、ユーザーの名前をクリックすることによってユーザー情報を編集できます。ユーザー属性の詳細については、「ユーザー属性」を参照してください。実行できるその他の変更には、次のものがあります。
変更するユーザーの名前をクリックします。
「ロール」または「グループ」を選択します。ユーザーにすでに割り当てられているロールおよびグループだけが表示されます。
「利用可能」リストからロールまたはグループを選択して「追加」をクリックします。
ロールまたはグループが「選択」リストに表示されたら、「保存」をクリックします。
サービスを追加するアイデンティティーを選択します。
「サービス」タブをクリックします。
「追加」をクリックします。
選択したアイデンティティータイプに応じて、次のサービスのリストが表示されます。
認証設定
ディスカバリサービス
Liberty 個人プロファイルサービス
セッション
ユーザー
追加するサービスを選択して「次へ」をクリックします。
サービスの属性を編集します。サービスの説明を見るには、ステップ 4 でサービス名をクリックします。
「終了」をクリックします。
Access Manager ポリシーエージェントは、Web サーバーおよび Web プロキシサーバー上のコンテンツを未承認の不正侵入から保護します。エージェントは、管理者によって設定されたポリシーに基づいて、サービスおよび Web リソースへのアクセスを制御します。
エージェントオブジェクトは、ポリシーエージェントプロファイルを定義します。また、Access Manager リソースを保護している特定のエージェントの認証情報やその他のプロファイル情報を Access Manager で保存できるようにします。管理者は Access Manager コンソールから、エージェントプロファイルを参照、作成、変更、および削除できます。
エージェントオブジェクト作成ページは、エージェントが Access Manager の認証を受ける UID およびパスワードを定義できる場所です。同一の Access Manager を使用して複数の AM/WS を設定した場合は、これにより、異なるエージェントに対して複数の ID を有効にすることができ、Access Manager から独立してそれらの ID を有効にしたり無効にしたりできます。また、マシンごとに AMAgent.properties を編集するのではなく、エージェントの設定値によっては集中的に管理することもできます。
「エージェント」タブをクリックします。
「新規」をクリックします。
次のフィールドの値を入力します。
「名前」: エージェントの名前またはアイデンティティーを入力します。これは、エージェントが Access Manager にログインするために使用する名前です。1 バイト文字による名前のみ受け付けます。
「パスワード」: エージェントのパスワードを入力します。このパスワードは、LDAP 認証時にエージェントが使用するパスワードとは異なっている必要があります。
「パスワードを確認」: パスワードを確認します。
「デバイスの状態」: エージェントのデバイスの状態を入力します。「アクティブ」に設定すると、エージェントで Access Manager に対する認証の実行および Access Manager との通信が可能になります。「非アクティブ」に設定すると、エージェントは Access Manager に対して認証を実行できなくなります。
「作成」をクリックします。
エージェントを作成したあとで、さらに次のフィールドを編集できます。
「説明」: エージェントの簡単な説明を入力します。たとえば、エージェントのインスタンス名や、エージェントが保護しているアプリケーションの名前を入力できます。
「エージェントキー値」: キーと値のペアでエージェントのプロパティーを設定します。このプロパティーは、ユーザーに関する資格表明の要求をエージェントから受け付けるために Access Manager によって使用されます。現時点では 1 つのプロパティーだけが有効であり、その他のプロパティーはすべて無視されます。次の形式を使用します。
agentRootURL=http:// server_name:port/
デフォルトでは、信頼できる環境で複数のポリシーエージェントを作成するときは、ポリシーエージェントに同一の UID およびパスワードが含まれます。UID およびパスワードが共有されるため、Access Manager はエージェントを区別できません。そのため、セッション Cookie が横取りされる可能性があります。
この弱点は、認証、承認、およびユーザーに関するプロファイル情報がアイデンティティープロバイダによって、サードパーティーまたは企業内の未承認のグループによって開発されたアプリケーションまたはサービスプロバイダに提供される場合に存在するようになることがあります。考えられるセキュリティー上の問題を次に示します。
すべてのアプリケーションは同一の HTTP セッション Cookie を共有します。このため、不正なアプリケーションがセッション Cookie をハイジャックし、そのユーザーが偽装によって別のアプリケーションにアクセスできるようになります。
アプリケーションが HTTPS プロトコルを使用していない場合、セッション Cookie はネットワーク盗聴される傾向があります。
1 つでもアプリケーションがハッキングされる可能性がある場合、インフラストラクチャー全体のセキュリティーが危険にさらされます。
不正なアプリケーションは、セッション Cookie を使用してユーザーのプロファイル属性を取得することができ、変更することも考えられます。ユーザーが管理権限を持っている場合、そのアプリケーションはさらに多くの損害を与える可能性があります。
Access Manager 管理コンソールを使用して、エージェントごとにエントリを作成します。
エージェントの作成時に入力したパスワードに次のコマンドを実行します。このコマンドは、エージェントがインストールされているホストで起動してください。
AccessManager-base/SUNWam/agents/bin/crypt_util agent123
次の出力が得られます。
WnmKUCg/y3l404ivWY6HPQ==
新しい値を反映するように AMAgent.properties を変更し、エージェントを再起動します。例:
# The username and password to use for the Application authentication module. com.sun.am.policy.am.username = agent123 com.sun.am.policy.am.password = WnmKUCg/y3l404ivWY6HPQ== # Cross-Domain Single Sign On URL # Is CDSSO enabled. com.sun.am.policy.agents.cdsso-enabled=true # This is the URL the user will be redirected to after successful login # in a CDSSO Scenario. com.sun.am.policy.agents.cdcservletURL = http://server.example.com:port /amserver/cdcservlet
新しい値を反映するように、Access Manager がインストールされている AMConfig.properties を変更し、Access Manager を再起動します。例:
com.sun.identity.enableUniqueSSOTokenCookie=true com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer com.sun.identity.authentication.uniqueCookieDomain=.example.com
Access Manager コンソールで、「設定」、「プラットフォーム」の順に選択します。
「Cookie ドメイン」リストで、次のように Cookie ドメイン名を変更します。
フィルタロールは、LDAP フィルタを使用して作成される動的なロールです。ユーザーはすべてフィルタを通してまとめられ、ロールの作成時にそのロールに割り当てられます。フィルタはエントリの属性と値のペア (ca=user* など) を検索して、その属性を含むユーザーをロールに自動的に割り当てます。
ナビゲーション区画で、ロールを作成する組織に移動します。
「新規」をクリックします。
フィルタロールの名前を入力します。
検索条件を入力します。
例を示します。
(&(uid=user1)(|(inetuserstatus=active)(!(inetuserstatus=*)))) |
フィルタを空白のままにすると、次のロールが作成されます。
(objectclass = inetorgperson) |
「作成」をクリックして、フィルタ条件に基づく検索を開始します。フィルタ条件によって定義されたアイデンティティーは、ロールに自動的に割り当てられます。
フィルタロールが作成されたら、ロールの名前をクリックして、そのロールに属するユーザーを表示します。「サービス」タブをクリックして、ロールにサービスを追加することもできます。
ロールのメンバーは、ロールを所有する LDAP エントリです。ロール自体の基準は、属性を持つ LDAP エントリとして定義されます。このエントリは、エントリの識別名 (DN) 属性で特定されます。ロールが作成されたら、サービスとユーザーを手動で追加できます。
ユーザーを追加するロールまたはグループの名前をクリックします。
「ユーザー」タブをクリックします。
追加するユーザーを「利用可能」リストから選択して「追加」をクリックします。
ユーザーが「選択」リストに表示されたら、「保存」をクリックします。
グループは、共通の職務、特徴、または興味を持つユーザーの集合を表現します。通常、このグループ分けに権限は関連付けられません。グループは組織の内部とほかの管理対象グループの内部の 2 つのレベルで定義できます。