|
Home > Archive > WebSphere Application Server > May 2004 > Implementing Custom Registry with Group Processing
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Implementing Custom Registry with Group Processing
|
|
| foobar 2004-05-26, 2:30 am |
| I would like to get people's technical opinion on implementing a
custom registry, specifically with respect to how group information
is processed. I'll provide enough technical detail to give you an
idea of each approach.
In solution one, we store the the names of the groups that users
belongs to in the repository itself along with the user information.
Suppose we are using a relational database to store repository information.
We would have a table where each row stores data for a given user, such
as their username, password, etc. We would also have a column or a
separate table that contains the names of the groups the user belongs to.
When we authenticate a user, we also retrieve their group information
and provide that to Websphere when it asks for it via the UserRegistry
interface. Websphere then maps the group ids to Roles that we set up
in the application.
In solution two, the application requires that the user indicate
which group(s) they belong to when they try to authenticate, via 2 or
more check boxes with the group names. We pass the group name(s) down
to the classes implementing the UserRegistry interface by prepending
them to the username. We would set up classes ahead of time that
handle each group name. Each of these classes would return the group
name back to Websphere when asked for them via the UserRegistry interface.
So we may pass down group1.joe/password and group2.bob/password. The
implementing classes would strip off the group names (group1 or group2),
and call checkPassword(joe, password) or checkPassword(bob, password).
When the implementing classes were asked what group group1.joe belonged to,
the class responsible for supporting group1 would return id "group1" in the
list of group ids that websphere wants, and the object responsible for
supporting group2 would return the id "group2", etc.
I was wondering what people's opinions are, pro/con of each approach,
and which they would recommend.
Thanks in advance.
| |
|
| In solution 2, what's the point to let people explicit the role they have
and how do you ensure they have the role they claim ?
BTW, there are DB2 and file-based samples of custom registry in the
InfoCenter you may want to have a look at.
| |
| paul_gover@uk.ibm.com 2004-05-27, 4:34 pm |
| Option 2 is rediculous. As specified, any authorised user can claim to
be an administrator. So they could turn of security! Group membership
must be authenticated, as well as userid.
In Option 1, you normally have three tables, one with userid and encrypted
password and user details, one with groupid and group details, and a third
with userid and groupid only, which contains a set of rows for each group,
the rows in the set corresponding to each member in the group.
As the other respondent said, there are plenty of examples for you to look
at.
| |
| Paul Ilechko 2004-05-27, 4:34 pm |
| foobar wrote:
> I would like to get people's technical opinion on implementing a
> custom registry, specifically with respect to how group information
> is processed. I'll provide enough technical detail to give you an
> idea of each approach.
>
> In solution one, we store the the names of the groups that users
> belongs to in the repository itself along with the user information.
> Suppose we are using a relational database to store repository information.
> We would have a table where each row stores data for a given user, such
> as their username, password, etc. We would also have a column or a
> separate table that contains the names of the groups the user belongs to.
> When we authenticate a user, we also retrieve their group information
> and provide that to Websphere when it asks for it via the UserRegistry
> interface. Websphere then maps the group ids to Roles that we set up
> in the application.
>
> In solution two, the application requires that the user indicate
> which group(s) they belong to when they try to authenticate, via 2 or
> more check boxes with the group names. We pass the group name(s) down
> to the classes implementing the UserRegistry interface by prepending
> them to the username. We would set up classes ahead of time that
> handle each group name. Each of these classes would return the group
> name back to Websphere when asked for them via the UserRegistry interface.
> So we may pass down group1.joe/password and group2.bob/password. The
> implementing classes would strip off the group names (group1 or group2),
> and call checkPassword(joe, password) or checkPassword(bob, password).
> When the implementing classes were asked what group group1.joe belonged to,
> the class responsible for supporting group1 would return id "group1" in the
> list of group ids that websphere wants, and the object responsible for
> supporting group2 would return the id "group2", etc.
>
> I was wondering what people's opinions are, pro/con of each approach,
> and which they would recommend.
I think option 1 is definitely preferable. You want group definitions to
be maintained by administrators, not be users themselves (how can you
trust them to be honest?). Also, group membership does not change
frequently, so having to dynamically pass it for every call is very
wasteful.
| |
|
| One scenario where I can imagine one mentions his role would be when one
wants to act with less privileges then one is actually authorized without
requiring two accounts (if roles are such that they give cumulative rights).
It's maybe not the best example, but with a bit of imagination I can
reasonably imagine me log into the console with Monitor role when I only
want to check a few settings and relog if I realize I need to change things.
Remains the fact that the Custom User Registry implementation has to be able
to validate that one has at least a role, which the OP's second
implementation is missing.
|
|
|
|
|