Arved,
I took a look at the scenario you describe, and I was able to make method
permissions work with roles as they should.  If a user who was part of the
users group was logged in, an exception would be trown.  If the user was
added to the CSR group everything worked.

Let me describe my orion security setup as it is somewhat complex, but I
have no doubt it will work with any properly written user manager.

I use a custom user manager I built on two database tables (I wanted
password encryption).  One contains users, and the other contains group
membership.  Since I was in a hurry when I wrote the UserManager I let orion
manage the groups themselves through it's XML implementation, hence the
principals.xml below.

Below are related excerpts from my configuration files.  I can't really
provide a working ear file, but I'm pretty sure the example ATM application
uses method level permissions, so it might be a good place to experiment.
In case you're interested, you can find my Custom user manager
implementation at
http://www.geocities.com/vanha/usermanagerImp.jar.
Its somewhat sloppy as I worte it in a real hurry, but it may provide some
useful info.


application.xml:
        <security-role>
                <role-name>user</role-name>
        </security-role>
        <security-role>
                <role-name>csr</role-name>
        </security-role>

orion-application.xml:
        <security-role-mapping name="user">
                <group name="users" />
        </security-role-mapping>
        <security-role-mapping name="csr">
                <group name="csr" />
        </security-role-mapping>

principals.xml:
        <groups>
                <group name="csr">
                        <description>service</description>
                        <permission name="rmi:login" />
                        <permission name="com.evermind.server.rmi.RMIPermission" />
                </group>
        </groups>

ejb-jar.xml:
                <security-role>
                <role-name>user</role-name>
                </security-role>
                <security-role>
                <role-name>csr</role-name>
                </security-role>
                <method-permission>
                        <description>Restricted</description>
                        <role-name>csr</role-name>
                        <method>
                                <ejb-name>Product</ejb-name>
                                <method-name>*</method-name>
                        </method>
                </method-permission>





-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Arved
Sandstrom
Sent: Tuesday, September 19, 2000 7:26 AM
To: Orion-Interest
Subject: RE: User/Group manager guide


I'm looking forward to docs and examples myself.

One thing that I've noticed, after copious experimentation with the
DataSourceUserManager, is that the group <=> mapping is somewhat deficient.
In other words, I have my users and groups tables set up, and I've made
suitable mods and adjustments to principals.xml, orion-application.xml,
ejb-jar.xml, and orion-ejb-jar.xml as required (or suggested). In some cases
I'm flailing about, frankly.

In any case, a login with username and password is obviously finding the
group, and mapping the group to role, because when I check the role after
login it's OK. I don't have to hardcode it, which is vital.

However, and I've tried everything, I don't believe this knowledge is being
passed on to the EJB container. No role, however declared in the various
J2EE/Orion descriptors, is able to access *any* method in an EJB that has
method-permissions.

So my assessment on the user/role managers is that it is reasonably useful:
one can assign roles based on login, and test for that as required. But
method-level security in EJBs does not work, at least not in a documented,
demonstrated and reliable manner.

The odd thing is, is that this may not be that much of a big deal. I've been
writing J2EE for pretty much a full year, and I have yet to see a situation
where method-level permissions gain me anything at all. It's literally never
been necessary. It seems to be one of these J2EE things that made ostensible
sense at the time but has little practical value. Just a thought.

The only reason it disturbs me is because it should work and doesn't. :-) If
an example can be supplied - complete with Orion-specific deployment
descriptors - I'll be overjoyed.

Arved Sandstrom

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Lawrence Fry
Sent: Monday, September 18, 2000 6:36 PM
To: Orion-Interest
Subject: RE: User/Group manager guide


Guilherme,

Here Here! I'm glad somebody said it.

But without documentation, you should look at the archives to this list,
because many of these problems have already been worked out.

For example...it isn't said anywhere in the documentation, but the
EJBUserManager is the most useful device for ecommerce. With this, you can
automatically login users and create users  for your website...without one
call to the EJBUserManager stuff. In order to use this, you will have to add
the following to your orion-application.xml file:

        <user-manager class="com.evermind.ejb.EJBUserManager">
                 <property name="home" value="com.evermind.ejb.EJBUser" />
                 <property name="defaultGroups" value="users" />
        </user-manager>

I found this tidbit in the mail archive. Then you can use the role manager
to allow users access to ejb resources, and the role manager automatically
uses the your databank with cmp to create users....create a user like this:

try
{
RoleManager roleManager = (RoleManager)new
InitialContext().looku("java:comp/RoleManager");
if(roleManager.getPrincipal(username) != null)
                                throw new DuplicateAccountException(username)
Principal principal = roleManager.createPrincipal(username, password);
roleManager.addToRole(principal, role);
roleManager.store();
}
catch(NamingException e){}
catch(UserAlreadyExistsException e){}
catch(InstantiationException e){}
catch(IOException e){}

and like magic, a user database is created. Of course, you also have to make
sure your roles are part of your groups.

This is the great secret of orion...great stuff, no documentation! It took
me weeks to figure this out. I wish there was a tutorial on these simple
issues:

How do you login in a client through a database of usernames/passwords?
How do you enroll a client into a database of usernames/passwords?
How do you control access to web resources (ejb's, jsp's, servlets)?

The existing documentation on this is about as clear as mud.

Regards,

Lawrence




-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Guilherme
Ceschiatti
Sent: Monday, September 18, 2000 1:58 PM
To: Orion-Interest
Subject: User/Group manager guide


Hi!

I'm almost leaving Orion because the lack of documentation, mainly about how
to
manage User/Groups. As many people have lots of doubts related to it too,
I'm
asking the Orion team or anybody else to write a tutorial about it.  I
really
don't want to leave Orion, because I've made good things on it, but I'm
spending a lot of time trying to "decifrate" how to use the Orion API.

Thanks.
Guilherme Ceschiatti
[EMAIL PROTECTED]




Reply via email to