WebLogic Domains/Admin Console Users Management
You are on the hook to deliver SLA for live production applications and challenged by any of the following issues – It is a sign that your WebLogic domains user management needs serious look.
- Primary support person becomes unavailable and rest of the support staff makes panic calls to locate Web Logic domain admin credentials.
- WebLogic deployments are sprawling in your enterprise environment - There is not audit trail to find who made what change when.
- Support team members needs roles/responsibilities based access of WebLogic domains in your enterprise.
- WebLogic domain user credentials are deceptively simple.
It is very common that, business application users are authenticated/authorized with external data source (LDAP, Database) to access secured application's web resources and J2EE resources as part of the basic application's security requirements.
It is also common that, each Weblogic domain stores domain user credentials in individual default store (Embedded LDAP) due to lack of enterprise wide user management requirements. It creates user management nightmare if you have large number of WebLogic deployments and equal number of support staff with different roles (Deployer, Operation, Development Support ) and responsibilities ( X person is responsible for application Domains A , B and F).
WebLogic domain and admin console user management can be streamlined by using enterprise wide common data source (i.e. LDAP or database). Domains can be integrated external data source using WebLogic security providers.
Basic WebLogic admin and domain user management will allow,
- to establish identity for each support staff member.
- to grant/revoke access to WebLogic domains/admin consoles as per need basis - By assigning users in different groups/roles.
- to create audit trail to understand who made what change when - using WebLogic audit provider.
- to use external datasource’s admin tools capabilities - i.e. Iplanet LDAP user and group management.
- to enforce enterprise wide security standard for credentials.
Key Considerations
Domain my need to be configured with more than one authentication modules.
- Authentication module for application users
- Authentication module for WebLogic domain/admin console users.
In this scenarion,
- Application user authentication events can skip enterprise login module(for domain/ admin console users) - To prevent performance hit for application user authentication requests. It can be acheived by
JAAS control flag .
- Application users can be blocked from domain/admin console access by defining global roles for domain/admin console users only.
Configuration efforts
WebLogic provides pre-built authentication provider for well known data sources, i.e. Iplanet LDAP, Open LDAP, RDBMS, Active Directory.
It will take some configuration efforts to integrate existing domains with external data source.
Domain provisioning process using domain templates can automate configuration process for new domains deployment.
Domain and admin console access availability.
Domain and admin console availability depend on the availability of the external data source just like, live production application’s on it’s database.
If external data source becomes unavailable, It is possible to roll back domain configuration to use default embedded LDAP datasource by copying back original config.xml and LDAP files.
- Primary support person becomes unavailable and rest of the support staff makes panic calls to locate Web Logic domain admin credentials.
- WebLogic deployments are sprawling in your enterprise environment - There is not audit trail to find who made what change when.
- Support team members needs roles/responsibilities based access of WebLogic domains in your enterprise.
- WebLogic domain user credentials are deceptively simple.
It is very common that, business application users are authenticated/authorized with external data source (LDAP, Database) to access secured application's web resources and J2EE resources as part of the basic application's security requirements.
It is also common that, each Weblogic domain stores domain user credentials in individual default store (Embedded LDAP) due to lack of enterprise wide user management requirements. It creates user management nightmare if you have large number of WebLogic deployments and equal number of support staff with different roles (Deployer, Operation, Development Support ) and responsibilities ( X person is responsible for application Domains A , B and F).
WebLogic domain and admin console user management can be streamlined by using enterprise wide common data source (i.e. LDAP or database). Domains can be integrated external data source using WebLogic security providers.
Basic WebLogic admin and domain user management will allow,
- to establish identity for each support staff member.
- to grant/revoke access to WebLogic domains/admin consoles as per need basis - By assigning users in different groups/roles.
- to create audit trail to understand who made what change when - using WebLogic audit provider.
- to use external datasource’s admin tools capabilities - i.e. Iplanet LDAP user and group management.
- to enforce enterprise wide security standard for credentials.
Key Considerations
Domain my need to be configured with more than one authentication modules.
- Authentication module for application users
- Authentication module for WebLogic domain/admin console users.
In this scenarion,
- Application user authentication events can skip enterprise login module(for domain/ admin console users) - To prevent performance hit for application user authentication requests. It can be acheived by
JAAS control flag .
- Application users can be blocked from domain/admin console access by defining global roles for domain/admin console users only.
Configuration efforts
WebLogic provides pre-built authentication provider for well known data sources, i.e. Iplanet LDAP, Open LDAP, RDBMS, Active Directory.
It will take some configuration efforts to integrate existing domains with external data source.
Domain provisioning process using domain templates can automate configuration process for new domains deployment.
Domain and admin console access availability.
Domain and admin console availability depend on the availability of the external data source just like, live production application’s on it’s database.
If external data source becomes unavailable, It is possible to roll back domain configuration to use default embedded LDAP datasource by copying back original config.xml and LDAP files.
posted by Jayesh Patel at
4:22 PM
1 Comments
