only first admin user should be allowed to create new admin users

The suspend user account (see comment in #423) should take care of it. It is possible to create all these hierarchies - but what happens, when the 'super'-'super' abuses admin previlages. So ... disabling the account is simple and effective and is a better option.

the problem is that i have no notification when a new admin user is created, and no way currently to list admin users (i'm working on that).

so it's possible for someone to create a new admin account and have it go unnoticed for some time unless i run a query on mulgara to list admins. i still don't have such a query, so right now i have no clue!

i also have no way to be notified of or track admin actions - when an annotation was deleted, by who, etc. so it gets scary quickly.

having an admin hierarchy is a normal thing - it has a long and relatively decent history! the minimum amount of trust should be granted, which means that different admins have different privileges.

but i'm not asking for a big new feature for admin permissions and hierarchy.

i'm just asking if there's something *easy* we can do - like only allow user 1 or the first admin to access the assignAdminRole.action - to give us some protection.

feel free to say no, and i'll make a bugs ticket and forget about it :)

Not right now. This requires the larger concept of roles and we planned that for later half of this year.

Replying to russ:

the problem is that i have no notification when a new admin user is created, and no way currently to list admin users (i'm working on that).

You have to pay particular attention to the XACML audit log entries. (These are the ones that show up as 'DenyBiasedPEP'). It should be simple enough to configure the log4j.xml to write these out in a separate file. And may be a perl script to monitor and notify actions that are allowed by 'permit-admin' policies etc.

so it's possible for someone to create a new admin account and have it go unnoticed for some time unless i run a query on mulgara to list admins. i still don't have such a query, so right now i have no clue!

If you see a DenyBiasedPEP log entry with a permit-admin policy that allowed a userRoles:setRoles action, then you know something is up.

i also have no way to be notified of or track admin actions - when an annotation was deleted, by who, etc. so it gets scary quickly.

Same - monitor the XACML logs and do whatever admin actions you want. This is exactly the reason why they are there in the first place.

having an admin hierarchy is a normal thing - it has a long and relatively decent history! the minimum amount of trust should be granted, which means that different admins have different privileges. but i'm not asking for a big new feature for admin permissions and hierarchy. i'm just asking if there's something *easy* we can do - like only allow user 1 or the first admin to access the assignAdminRole.action - to give us some protection.

Sure. You can always add that into the XACML policies at production. The ones in the RPM are meant to be a reasonable defaults only. They are meant to be extended by admins for precisely the reasons you stated. You can define a new XACML policy that says for example userRoles:setRoles can only be performed by user 1 etc. and add it into the appropriate policy-set.

feel free to say no, and i'll make a bugs ticket and forget about it :)

:) The mechanisms are all in place. You have been running with out-of-the-box config so far. It is time to explore some of the flexibilities we have built into the system by having your own XACML rules and also making use of the audit-trail for monitoring etc.

See http://gandalf.topazproject.com/trac/wiki/XacmlSecurity

excellent! thanks. i'll reassign to myself for further investigation.

Replying to pradeep:

See http://gandalf.topazproject.com/trac/wiki/XacmlSecurity

Try this link instead: XacmlSecurity?

Milestone WishList? deleted