Section access - authorize groups only

[#1]

Hello,

I am trying to use webtickets (configured with DMS authorization and Custom User authentication)

and pass certain groups so that only user belonging to a group can see a document.

I am using QV11 with IIS

With a php script I pass the following xml

<?xml version="1.0"?>

<Global method="GetWebTicket">

<UserId>MYUSER</UserId>

<GroupList><string>GROUP1</string></GroupList><GroupsIsNames>true</GroupsIsNames>

</Global>

And the document has the following section access

Section Access;
LOAD * INLINE
 
[ACCESS,GROUP
ADMIN, GROUP2
USER, GROUP3
];

so only users with GROUP2 and GROUP3 should be able open the document

Anyway, no mather which Group I pass with php, I can always open the document.

Is it possible to pass groups only? If yes, is there anything wrong with my code?

[marcus_sommer]

I'm not sure if an authorization with user-groups is possible per DMS-mode. The authenticated user itself will be handled like a NT user but groups - I don't know. For this you need to add NTNAME as key-field into the section access the GROUP isn't such a key-field. You could it only use for horizontally restrictions. I think this will helpful for you: Introduction to Section Access and very important: make a BACKUP from your app before you going further.

- Marcus

[#3]

So must I add all users in the section access?

This is not feasible as have thousands of users and they come and go everyday.

So I cannot use a static solution  like the section access, can't I?

Do you see another possibility to set authorization by groups only?

The document you passed me is interesting and I'll give a thorough read pretty soon.

[datanibbler]

Hi icsinqlik,

I don't think that SA (section access) is the right means to achieve what you want - you could load all the individual names acc. to those groups from some database or file - but SA has to be the very first thing in your script, so that won't work.

What you can do is (I don't know whether it would work in a trigger or you'd need a macro, try it out) to launch a routine, upon opening the document, checking the logged-in user (OSUSER()) against a list which you have loaded beforehand from your personnel-database or some file and if the user is not part of the list, close the document.

Of course, that could be worked around (by disabling macros when opening the app) but it's better than nothing ...

Or - make a second app which just queries the currently logged-in user, checks him/her against a previously loaded list and if it does match, saved a small qvd which passes some small token to the SA in the second app (like a username and password) - I don't actually know if that is doable, it's an idea I had just now - and then call that second app via document_chaining - and if and only if the first app declared that user as authorized, he/she will be able to open the actual one - direct opening of that app won't be possible anymore since that token would not match any real OSUSER.

HTH

P.S.: To be honest, that is just built upon a solution that someone here in the Community gave me for an app that is supposed to be used by people all over the place who will have the technical possibilities to mess it up - but they shouldn't, so everyone who does not know a specific password - AND have a specific second app - can only open that with USER privileges.

[#5]

The fact about your ideas, is that I always have to specify all users in a list.

Unfortunately I can't do that because I the users because change every day (and possibily at any moment)

It would be not feasible to export them and I have problems to query the user database.

This is why I wanted to authorize groups  only.

[marcus_sommer · Accepted solution]

In general such approaches mustn't be static. But I think it must be viewed a bit more differentiated. Section Access is only the part of authorization which is applied on a single application-level and you will need to use at first a higher authorization-level on user and user-group level.

I use DMS with custom users, too but create the user and usergroups manually which meant not much maintaining efforts because we use functional users like area_1, area_2 ... instead of personal users like john, mike ... I suggest you rethink your intended approaches of authenticating and authorizations and consults a partner with experience for this then afterwards changes could be very expensive.

- Marcus

[#7]

I had thought about a  similar approach to work around. Anyway, I'll consult a partner to check that the solution holds.