I’m looking at the security implelmentation in Tamino.
I’ve secured my database that unknown users can’t see my collection. For that I’ve create for the database a group with an access control list defining nobody has default access to my collection.
For the known users I’ve defined a group TEST with in that group all the known users and also an access control list defining that all knwon users have full access.
Now I’m trying to get data out of the collection via the Interactive Interface. This one tells me that the collection is not exisitng due to the security issues (default is ‘no’ access).
The question I have is : how can I specify a userid and password when using the Interactive interface so that I can specify a knwon user to get data out of my collection?
if you have defined security in your web server (this is a prerequisite to use Tamino Security) then, in TII when you click on “Query” buttom (or any other) the web server authentication window appears (asking for user and password).
In the mean time I’ve been searching a litlle bit, and I’ve found another item describing this issue too. I’ve activated the Web Server security, so that thez browser asks me for a valid userid and password. When OK, this one is passed to the Tamino server, where it is also validated (definitiona via security manager).
At this moment the TII is working like I would expect, but I’m checking also the other tools like X-Plorer and Schema editor. Also there you have to login with userid and password which is verified at the Web Server? But afterwards I have some strange behaviour :
X-Plorer : Even when I’ve been logged on with a valid userid and password, the next query I try to execute gives me the execption that the specified collection isn’t existing, but this one exists. The program reacts the same as it would when I’ve been logged on with a unknown Tamino user ??
Schema Editor : When I logon with a dummy user, defined in the WebServer but default authority in Tamino (this means no access!), then I’m able to see all the schema information!
Does the X-Plorer and Schema Editor use also the HTPP interface?
I’m gone test also my application which uses the new Java API using the following code to connect to the server :
connection = TConnectionPoolManager.getInstance().getConnection(taminoServer);
In the ManagedConnectionPools.xml file a correct userid and password is specified.
I will test the X-Plorer behaviour.
About Schema editor, did you protect in your ACL’s the ino:collection collection ?
This collection is from which Tamino Schema Editor reads the Schemas information.
Oeps… I’ve overseen this one. Now I’ve defined a default access control list element for ino:collection with ‘no access’ and another access control list element for ino:collection with ‘full access’. The first one is defined in the database group, so that every unknown user is getting this rule. The second one is defined in a group a normal user is assigned to. This should mean that every jnown user must be able to see the collection information. This is apparenty not the case, when I log on wiht a correct user I never see any inof of ino:collection.
I have the same strange behaviour using a Java Application and also with X-Plorer. See also item in discussing forum Java API reased by me.
X-Plorer tested, this is what I found:
Connect to database with a user not defined in web server —> then an exception appears telling you that can’t connect to database.
Connect to database with a user defined in web server and not defined in Tamino Security —> then I can see all the information in my database.
Connect to database with a user defined in web server and defined in Tamino Security (I have an ACL for this user (his group)which doesn’t allow this user to access to my “libros” collection (access=no)) —> then I can connect to datbase, see all the collections names (“libros” too), but an exception appears when I try to expand the doctypes inside “libros” collection.
I think is the CORRECT behaviour, don’t you?
I have the following security setup :
My Tamino database is called TEST.
I’ve created the following users :
I’ve created the following groups :
TEST (same as the database, default security rules)
USERS (contains the user TaminoUser)
ADMIN (contains the user TaminoAdmin)
I’ve created the follwing access control lists :
DEFAULT_ACL setting all the used collections to ‘no access’ (business collections, ino:security and ino:collection). This list is assigned to the TEST group. Meaning all the unknown Tamino users want see anything.
SECURITY_ACL setting the ino:security collection to ‘full access’. This list is assigned to the ADMIN group. Meaning that only users belonging to the group ADMIN may change the security rules.
TEST_ACL setting the ino:collection and business collection to ‘full access’. This list is assigned to the ADMIN and USERS group. So all the known users may see and change the data in the business and ino:collection collections.
Now when I use a business Java application, the X-plorer or even the schema editor connecting to the TEST database using the user TaminoUser then the connect works fine but I can’t see any data. Normally this TaminoUser should see everything based on the set security rules.
if you define a group with the database name “TEST”, then ALL users belongs to this group although you define an specific group for each user. !!!
If you want an ACL by default for all users not defined in Tamino you need an ACL named as database “TEST”.
Ooops… the last one post could be my mistake.
Doing further tests…
You tell me that that an ACL should be defined with the same name as the database so that access by an unknown tamino user will get these rights. I’ve changed it and now everybody, even unknown users, get access to the data.
When you take page 5 of the Tamino Security documentation, the sample is just showing that you have to use a group with name the database name, assign an ACL where the access is set to ‘none’.
Is ther more info (documents) describing the setup of the Tamibno security for default access?
Sorry, You are right, theoretically that is the correct way (create a group with database name) and restrict its permissions, but it seems to me that is not working …
In my tests security configuration I hadn’t that group, so all worked fine, and now when I have defined it I can see that everybody has the permisions of this group.
I will continue doing tests and trying to find the reason for this behaviour.
I don’t know additional documentation.
It’s correct that a group named like the database is used by every user, known or unknown. So the sample in the security book is correct because by default known or unknown users have by default NO access to the ino:security collection. Only the users belonging to a group haveing ACL with ‘full’ access can see data in the ino:security collection.
Now what I like to establish is the same for the business collection and the ino:collection collection.
I’ve used the same techique for this. The ACL for the group is set to ‘no’, meaning that every user has no access to the data. Only the users belonging to a group having an ACL with ‘full’ access ACL can see and update the data.
Based on my definitions this behaviour is perfectly working in the TII, but NOT in X-Plorer and business Java application.
it seems to be correct behaviour.
Please, look at the documentation (page 7, just before “Example ino:group instances”):
"If there is a group defined to the system, which has a group name identical to the name of the Tamino database in question, all defined and undefined users are regarded as members of this group. This means that all Tamino users have access to all ACLs referenced by this group."
What the documentation is mentioning is correct and this is also have it behaves when the group with the database name is defined. The users will get these rights. Thats’ why I said ACL that tells Tamino that nobody has access to my collection. BUT, I have defined a second group where the known users are added to, and for this one another ACL is defined telling that these persons have full access to my collection. But Tamino doesn’t seems to take this one. It looks like he has found the default one and takes this without seeing if there is a group where the higher rights.
Like I told you it seems to work correctly for the security one, but I don’t understand why it doesn’t for my business one?
Additional info to the previous reply. The behaviour seems to work 100% corrent in the TII!
I think that there is a problemn in the storage of my security information. When I try to change the ACL for the group containing the known users I have the following exception :
INOXRE8814 Element/attribute name not found
So it seems that somewhere data is corrupted, and this may cause my problems.
I’ll investigate this a little but further.
This last one is a strange one :
I have two ACLs containing the floowing definitions :
NODE1 no access
NODE2 no access
NODE3 no access
NODE1 full access
NODE2 full access
NODE3 full access
Now I assign ACL1 to GROUP1 : ok
The I assign ACL2 to GROUP2 : ok
Modify the ACL1 again, make no changes and click OK button : INOXRE8814 Element/attribute name not found execption is given
First of all, I can’t reproduce your last problem definition, but something related (I think).
I have been doing some tests and I think I have found how to make it work (with some points to refine). These are my conclusions:
1.- Create a user “administrator” of group “administrators” with an ACL “fullaccess” which have permission=full for all collections in my database:
NOTE: This user must be the same that the administrator of Tamino Manager. If administrator of Tamino Manager has restricted access to ino:security I have found some errors responses when modifying my security definitions (for example: INOXRE8811)
This is the thing that I said before is (maybe) related to your last problem (access to anyplace are forbidden).
2.- Create a group named as database “TEST” with an ACL “noneaccess” which have permission=no for all collections in my database:
This is the permissions of any user authenticated on the web server and non-existent in Tamino.
3.- Create a user “readuser” of group “readers” with an ACL “readacl” which have the following permissions:
With this security definitions these are my results:
i) Tamino Manager
user Administrator (defined as Tamino administrator) can manage security.
user Juanjo (defined as Tamino administrator but not in Tamino security, can not manage security.
Due to the fact that you didn’t authorized the user for the ino:collection, most of the read operations will fail! You must give ‘readuser’ at least read authority on the ino:collection class.