The RoleManager depends entirely on the Useranager implementation that any
given app is using.
(If you decompile RoleManager, you'll find that it calls
Application.UserManager's methods quite often)
Roles in J2EE (RoleManager) map to groups in UserManager.
I use three tables; one has user/password info, one has group definitions
(roles), and another has user/group relations
I will be much clearer once you start coding and testing...
Oh, and whenever an app is first deployed, Orion (thru RoleManager then thru
UserManager) will attempt to create a group
for each declared role in every web.xml & ejb-jar.xml that finds within the
application. That part of the init is automagical...
I've had to make a back-end to the security(to create, edit and remove
security data). You will have to create a user
with access rights to this backend to start(in my case, a user:"sa"
password:"" that was linked to a securityAdmin group).
As a side note, this security is also used to access JNDI, and I haven't
played much with it, but you'll have to check out
the orion-XXXX.xml for namespace tags to enable read/write access to Orion's
JNDI implementation. (Has a lot to do with the getAdministratorUser() in
UserManager)
HTH
Juan Pablo
-----Original Message-----
From: Nick Newman [mailto:[EMAIL PROTECTED]]
Sent: Viernes, 19 de Enero de 2001 15:24
To: Juan Lorandi (Chile)
Subject: RE: Writing user managers
Sounds like it's not too hard. Great!
One further question if I may. If Orion supplies its own implementation of
the RoleManager which we cannot change, then does that mean we cannot
specify the group-role mapping through anything but the xml files? Or is
there some way that we could persuade Orion to use group-role mappings that
are defined in a DB?
Thanks,
Nick
At 12:51 PM 1/19/01 -0300, you wrote:
>Group, User, and UserManager.
>
>Group and User are almost data transports; UserManager is where the work
is,
>but if you know a little of connectivity (say, you want persisted security
>information in a DB, the jdbc is a must, or java.naming for LDAP, etc)
>wouldn't take more than 20 man hours. RoleManager is a class, and it's
never
>implemented by the user. Supposedly, it's the neutral way to use security,
>it works with roles, etc. If you have a functional UserManager
>implementation, any code you write firing upon RoleManager will survive a
>UserManager implementation change (or at least that's the idea)
>
>HTH
