This content has been marked as final. Show 3 replies
1) The security attributes are OR'd together so if the user has any ONE of the attributes (either client ID or role ID), the document can be seen by the user. What I would try is to create a view to call rather than directly against the table. The view can then leverage a PL/SQL function and encapsulate the logic behind the security tokens to return.
So the view would look like this...
CREATE OR REPLACE VIEW USER_SECURITY_V AS
MY_SECURITY_FUNCTION(USER_T.ID) AS AUTH_ID
The PL/SQL function would look something like this...
CREATE OR REPLACE FUNCTION MY_SECURITY_FUNCTION(USER_ID NUMBER) RETURN VARCHAR2 IS
-- Do whatever you need to do to build a single space-deliminted list of tokens for both Client and Role ID "CLIENTID4 ROLEID5 ROLEID9" then return
The data source authorization query then would look like this...
SELECT AUTH_ID FROM USER_SECURITY_V A WHERE A.ID = ?
Using a PL/SQL Function to control the tokens gives you the flexibility of modifying security without having to touch the data source directly
2) I don't quite follow. If any ONE of the tokens match, the document is returned. If the role ID is null, you might try stamping each document a "master" security token indicating it's open to everyone such as "ALL". Then in the PL/SQL Function, return "ALL" in front of the actual values.
The crawler logs will only tell you what is indexed at crawl time, not how searching is actually working. Try checking the server logs. These should be under something like oracle/ses/seshome/search/base_domain/servers/AdminServer/logs
Hope this helps!
I think you'll find that if there are multiple security attributes (rather than multiple values for the same attribute) then the attributes are ANDed - the user must have a match against BOTH / ALL of the security attributes.
Within any attribute, the values should be space-separated as Stephen says.
Thanks Roger for clarifying, great point. In the past I have used a single security attirbute with multiple values and if the user was found to have any of them, then the document was returned.
So each document was tagged with one or more security tokens in a single columns, including a master "ALL" token such as...
"ALL SECTOKEN1 SECTOKEN2 SECTOKEN3..."
In this case the values are OR'd together. The Function would check who the user was (Admin, Super User, Manager, etc) based on their employee information and returned the appropriate tokens.