Description :
In this article, we will see the workflow of WAMUI in detail for three different cases.
Case 1 : Login to WAMUI (connected to multiple PS) using any user account
1) On clicking the Sign In button, WAMUI will fetch external user directory details (from the internal derby DB) and connect to the same.
Note : External User directory details will be stored in derby DB while configuring Administrative Authentication(from WAMUI).
2) It will compare the credentials provided by user with the one which is stored in external user directory. If the authentication failed, you will be getting the error message saying “Error: Username and password do not match.”
3) If the authentication is success, WAMUI will get shared secret key and other required details of the server(from the internal derby DB) which is selected by the user(in server dropdown of WAMUI login page).
Note: Policy server detail, shared secret key and other details will be stored in derby DB while registering Policy Server Connection(from WAMUI).
4) It will use the corresponding shared secret key (and other details like port number etc..) to establish a connection with the policy server.
5) Policy server will compare the shared secret key provided by WAMUI with the one which is in the corresponding trusted host object of policy store.
Note : Trusted Host object (related to WAMUI) with hostname, shared secret key and other details will be created in policy store on either of the below cases.
- while connecting to Policy Server with WAMUI using superuser account (i.e., opening Administrative console for the first time)
- while registering Policy Server Connection(in already setup WAMUI).
6) If shared secret matches, connection will be established.
7) Now, WAMUI will present the LDAP DN of the authenticated user to the policy server to check if that DN has an associated Admin profile(XPS::Administrator object)
Note : CA.XPS::Administrator object controls privileges available to any user and thus control what options they see in the WAM UI interface. CA.XPS::Administrator object (related to user) will be created in any of the following cases.
- while connecting to Policy Server with WAMUI using superuser account (i.e., opening Administrative console for the first time)
- while creating an Administrator.
- while creating a legacy Administrator .
- while configuring Administrative Authentication (as we will be setting up superuser account during this process).
8) If no Admin profile exist for that DN, user will be able to login (but will not be able to view any Tasks) and following error message will be displayed.
9) If Admin profile exist for that DN but the user do not has permission to access the AdminUI, user will be able to login (but will not be able to view any Tasks) and following error message will be displayed.
10) If Admin profile exist for that DN and the user has permission to access the AdminUI, user will be able to view the Tasks, sub tasks (and other sections) according to his rights and scope.
Case 2 : Login to WAMUI (connected to single PS) using any legacy admin account
1) On clicking the Sign In button, WAMUI will get shared secret key and other required details from the conf file(<Installation path>/adminui/server/default/data/siteminder/<File Name>.conf) of policy server.
Note : This conf file is similar to SmHost.conf file. This file will be generated while connecting to Policy Server with WAMUI (i.e., opening Administrative console for the first time)
2) It will use the corresponding shared secret key(and other details like port number etc..) to establish a connection with the policy server.
3) Policy server will compare the shared secret key provided by WAMUI with the one which is in the corresponding trusted host object of policy store. If shared secret key matches, connection will be established.
4) Now, WAMUI will communicate with policy server for authentication of legacy administrator.
Note : Legacy admin credentials will not be stored in derby DB.
5) Policy server will compare the credentials provided by WAMUI with the credentials which is in the corresponding Admin object of policy store.
Note : CA.SM::Admin object with Name, Password, Rights etc.. will be created in policy store while creating a legacy Administrator (from WAMUI).
6) If the authentication failed, you will be getting the error message saying “Error: Username and password do not match.”
7) If the authentication is success, policy server will check the Admin profile(XPS::Administrator object) of corresponding Legacy Admin.
8) If the user do not has permission to access the AdminUI, user will be able to login (but will not be able to view any Tasks) and following error message will be displayed.
9) If the user has permission to access the AdminUI, user will be able to view the Tasks, sub tasks (and other sections) according to his rights and scope.
Case 3 : Login to WAMUI (connected to single PS) using superuser (siteminder) account
1) On clicking the Sign In button, WAMUI will get shared secret key and other required details from the conf file(<Installation path>/adminui/server/default/data/siteminder/<File Name>.conf) of policy server.
Note : This conf file is similar to SmHost.conf file. This file is generated while connecting to Policy Server with WAMUI (i.e., opening Administrative console for the first time)
2) It will use the corresponding shared secret key (and other details like port number etc..) to establish a connection with the policy server.
3) Policy server will compare the shared secret key provided by WAMUI with the one which is in the corresponding trusted host object of policy store. If shared secret key matches, connection will be established.
4) Then, WAMUI will compare the credentials provided by the user with the superuser credentials which are stored in internal derby DB.
Note : Superuser credentials will be stored in derby DB (in addition to CA.SM::Admin object of policy store). IAM framework stores the user credentials in encrypted form in derby DB
5) If the authentication failed, you will be getting the error message saying “Error: Username and password do not match.”
6) If the authentication is success, policy server will check the Admin profile(CA.XPS::Administrator object) of corresponding Admin for access permission, rights and scope.
Note : Not sure if this step will be performed as it may not be required.
7) User will be able to view all the Tasks of WAMUI.
Note : This article is based upon my analysis and the clarifications received from CA Community members and Engineering team (through RFI via Support Case). Feel free to let me know if there is any discrepancy.
Thanks,
Dhilip