Subscribe to the RSS feedImplicit Groups in WebLogic
WebLogic has some special groups which you would only learn about if you read the documentation. I know, that’s a good one! But seriously, there is a special group for authenticated users and one for all users which I’ll get to in a moment.
Default Groups
Per the documentation, BEA supplies several default groups. The four you probably know about are:
- Administrators
- Deployers
- Operators
- Monitors
You know about these default groups because they appear automatically in the list of groups within the security realm. Each of these groups is associated with an authentication provider and you can delete them if you wish (assuming you’re aware of the consequences). Furthermore, the documentation states that "users" and "everyone" are also default groups. However, I prefer to call these "Implicit Groups."
Implicit Groups
The implicit groups "users" and "everyone" are not associated with any security provider. Rather, you can think of them as virtual groups spanning all authentication providers. Membership in these implicit groups is dynamically handled by the server.
So, what are these implicit groups?
The "users" Implicit Group
Simply stated, any authenticated user is a member of this group. If an authenticated user otherwise has no group memberships (such as Administrators, StockTrader, etc.), he’ll still be a member of this group.
The "everyone" Implicit Group
All users are members of the "everyone" group whether they are authenticated or not. As such, an authenticated user will be in both the "everyone" and "users" groups. The "everyone" group seems a little silly to me because I can’t think of a good use for it but maybe I’m missing something.
In fact, I know I’m missing something because there is a default global role called "Anonymous." This global role maps to the "everyone" group. However, since the "everyone" group contains anonymous (i.e., unauthenticated) and authenticated users, an authenticated user would have the Anonymous role. Isn’t that like matter and anti-matter colliding?
Using Implicit Groups
What can you do with these puppies?
It’s important to realize that implicit groups are legitimate albeit hidden groups so you can use them for security constraints like any other group. In other words, you can map a role used by a security constraint to the "users" group. You can also query the mapped role with HttpServletRequest.isUserInRole() to see if the user has the role that maps to an implicit group. (NOTE: Don’t let WebLogic 8.1’s default mapping of roles to group names bite you when you move to WebLogic 9.x. See WebLogic 9.1 Authorization Gotcha for more information.)
For example, you might have a scenario where you want your initial web page to be accessible to any user who can authenticate. The user can then determine if they need access to the application and can click a link to request access. Other links deeper into the application would probably have security constraints with application-specific roles like StockTrader which our unprivileged yet authenticated user would not be able to access or even see.
Auditing and Implicit Groups
With the Default Auditor, authorization events include the groups to which the user belongs. But the implicit groups are so implicit that they aren’t listed! It actually makes sense after a moment’s thought — Authorization happens after authentication and an authenticated user is ALWAYS in the "users" and "everyone" groups by definition. As for anonymous users, they haven’t authenticated so there are no audit entries, anyway.
Parting Questions
Can you think of any other uses for implicit groups? Can you enlighten me on the usefulness of the "everyone" group? I look forward to hearing your ideas.
Assume you have a discussion forum application which defines an AuthorRole. Now, you want to deploy two instances of the application, one where only specific authenticated users are authors and one free-for-all, which doesn’t require authentication. How would you set up the latter without the everyone group?
Comment by Niels Harremoes — March 30, 2007 @ 2:40 am
Niels,
Thanks for the comment.
If I understand your scenario correctly, you’re mapping AuthorRole to the AuthorGroup for the first instance so that you can identify the specific users you mentioned. Correct me if I made a bad assumption especially since I read in some extra detail.
For the second instance you’re mapping AuthorRole to the everyone group in the hopes of allowing anonymous users to have the AuthorRole.
But from what I’ve seen, any security constraint in web.xml requires authentication even if the role ultimately maps to the everyone group. In that case, your second instance would still require authentication but the user would be otherwise unprivileged.
To answer your question, I would implement the free-for-all instance by removing the security constraints.
Here’s the sample app I used when writing the post. Perhaps if I’m configuring it incorrectly it will jump out at you.
Do you have a working example?
Thanks again.
Comment by Mike Fleming — March 30, 2007 @ 8:06 pm
You are right. I hadn’t thought about the everyone group requiring login.
But just removing security constraints and role mappings will probably not work, since the application is likely to use isUserInRole(”AuthorRole”) to determine whether to show the “Add new post” link.
Comment by Niels Harremoes — March 31, 2007 @ 3:40 am
Good point.
The solution to that might be to add a configuration setting and change the link condition to something like:
(isUserInRole(”AuthorRole”) || isFreeForAll())
Comment by Mike Fleming — March 31, 2007 @ 7:26 am
I am creating user in realm through API using MBeanServerConnection object and invoking createUser method . But that created user is not getting authenticated to weblogic it is giving AuthenticationException . Where this user created by createUser API is created means in which group or in implicit group coz it is shown in user list of realm and there is no group as such for that user created through API .
Comment by Chetan — September 24, 2007 @ 6:26 am
Chetan,
The implicit groups don’t need to be created (or have users added to them) because they already exist and users are “in” the groups under certain conditions which are handled automatically by the server. For example, a user is automatically in the “users” group after a successful authentication.
As mentioned in the post, if you want to use one of these groups, just create a role for your application that maps to the implicit group you want.
Since your user is probably not authorized to access your application, check the security constraints to make sure the role you used maps to the appropriate group.
You might find Troubleshooting Authentication Issues with Audit Logs useful…
Comment by Mike Fleming — September 24, 2007 @ 8:58 pm
In the last post i have sent the code i used to create user in realm . Please suggest me why my created user is not getting authenticated I am not using Role Policy i mean to say i am not using authorization part of weblogic only i am using authentication part . Help me .
Comment by Chetan — September 26, 2007 @ 3:41 am
Chetan,
Unfortunately, your code didn’t come through. However, I saw your posts on the BEA forums indicating that you are doing EJB lookups.
Does your client work with a user you manually created in WebLogic console?
Mike
Comment by Mike Fleming — September 26, 2007 @ 7:50 pm
Mike ,
thx a lot for ur response .
yes it works when i create user manually through weblogic console. then why the programatically created user is not able to get connection ?
Comment by Chetan — September 26, 2007 @ 11:43 pm
hi
Still i am stucked with the same problem . I have one other application which is having clustered environment and they have used the MBeanHome deprecated APIs to create user their code is running fine and there created user can also log in through application . but in my code i have used MBeanServerConnection to create user but it is not able to log in . Help me .
Comment by Chetan — October 8, 2007 @ 4:44 am
Chetan,
Have you tried the advice given in Troubleshooting Authentication Issues with Audit Logs? You really need to know if this is an authentication failure or an authorization failure. The audit log will tell you.
Also, you can send me your code at mike @ monduke dot com and I’ll have a look at it if you’d like.
Mike
Comment by Mike Fleming — October 8, 2007 @ 8:01 pm
hi
i tried the weblogic auditing. In the auditor log when my created user is going to login that time in audit log the entry is like follows :
#### Audit Record Begin
>>
Audit Record End ####
I couldn’t understood from this exactly where is the problem . Help me .
Comment by Chetan — October 17, 2007 @ 8:10 am
Chetan,
The message you emailed me contained the following event which didn’t come out in your comment above:
#### Audit Record Begin <Oct 17, 2007 5:21:41 PM><Severity =FAILURE> <<<Event Type = Authentication Audit Event><crc><AUTHENTICATE>>>
<FailureException =javax.security.auth.login.FailedLoginException:
[Security:090304]Authentication Failed: User crc javax.security.auth.login.FailedLoginException:
[Security:090302]Authentication Failed: User crc denied> Audit Record End ####
I’m just re-posting this here to see why some comments have trouble with code-like things and to potentially help future readers.
Anyway, my email response was this:
“That message is very helpful.
Assuming you only have one authenticator and that the user “crc”
exists, the only possibility is that the password is wrong.
Double-check your code.”
Comment by Mike Fleming — October 17, 2007 @ 6:56 pm