Reject or logout all users not belonging to "My webMethods Users"

, ,
1

Hi,.

I’m looking for a way to not allow logging in any user not belonging to the “My webMethods Users” role.

This is the natural behavior an isolate MWS (as all internal users are members of that role) but users from LDAP are authenticated and, even if not connected to that role, they have access to the MWS, albeit only to a non-functional base page.

Any suggestions? I thought on creating a login rule but I do not know which portlet to redirect them to.

Or maybe I’m missing a configuration in the Directory Service entry of the AD?

Thank you in advance,

Best Regards,

2

Hi Gerardo,

as soon as someone is member of “My webMethods Users” he will be able to login to MWS, but will have very limited possibilities then.

This is due to the fact that the most objects have access priviliges as Group “Everybody = none” as well as Role “My webMethods Users” not having any definition of these anyway (equals to none in my opinion).

As groups cannot contain externally defined users, these have to be added to roles directly.

Externally defined users need to be member of “My webMethods Users”, otherwise they cannot be assigned to any other Role.

Regards,
Holger

3

Hi,

I’m afraid I wasn’t very explicit: I want to reject or deny login to all AD-authenticated users which are NOT in the “My webMethods Users” role.

Maybe there is a way to logout them out immediately?

Best Regards,

1 Like
4

Hi Gerardo,

these users should be denied by default.

Regards,
Holger

5

Hi,

Strange, then there is some setting somewhere that allows that. What could it be?

All AD users get “Authenticated=true” result in the logs.

If they don’t belong to the “My webMethods Users” they only get the very basic folder view but they are in MWS, which poses a security risk.

Best Regards,

6

Hi Gerardo,

if the users are not assigned to any role in MWS they only should have “Guest” privileges.

You might want to open a support incident in empower to get some clarification from vendor.

Regards,
Holger

7

To clarify, the UI is different for members of the “My webMethods Users” role simply because the shell rules typically would map those users to one of the “Noodle” shells which presents the “workspace” style framing around each page (lefnav + workspace tabs). Users who are not members of that role are likely mapped to one of the Powerdrill shells (the same framing as you would see when logged in as sysadmin).

  1. Authentication simply validates that the supplied user credentials are valid. Role/Group membership shouldn’t be considered here.
  2. Authorization enforces the permissions model to limit what the user can see and do. Role/Group membership contributes to the rightset that is user is granted.

So a user that is not assigned to a specific role in MWS are not getting “Guest” privileges, they just won’t have the rights that were granted to the role that the user is not a member of.

In my opinion using the membership of a role to decide whether authentication is allowed is an odd solution as you are now mixing authentication with authorization. You would be better off by having the administrator provide an LDAP endpoint that only exposes the users that you want to have access to MWS. Or perhaps utilize the “userDisabled” configuration of your LDAP directory service to not allow login to MWS based on the value of some attribute in the user record in LDAP.

8

Hi,

Thanks for all the answers.

This is sounding stranger and stranger.

In terms of authorization, I have found more cases where you really only want a specific group of AD users to login, rather than exclude them.

As such, the reasoning of the “User Disabled” field is reversed: you only want those users which have a certain property (in this case, group membership).

I would have to create a negation regex (which is an anti-pattern) against the memberOf property. I’ll research what can be done to achieve this in MWS 9.9.

Any ideas are welcomed.

Best Regards,

9

Hi,

After further consideration, I realize that MWS is expecting AD users to be segregated by branches.

The trouble is that in my case, users are segregated by group membership and, by default, users should not be allowed to login.

The “user disabled” matching cannot be used here because I may want to signal users which are disabled in the AD and there is another specific field for that.

It seems I’m running out of options to solve this…

Any new ideas?

Best Regards,

10

Maybe it is possible to configure AD to provide a different (filtered) view of the user data to the client (MWS in this case)? Or some sort of “mwsUserDisabled” dynamic attribute in the LDAP user record that calculates a value from other information that is available there? I’m not an AD expert so I don’t know if that is possible.

From a security perspective, it would be best if the users who aren’t supposed to login to MWS are not visible to the MWS LDAP client when it communicates to the remote LDAP server.

If the users are still visible to the MWS client, they would probably show up in the user picker and user search UI of MWS even if you can’t login as those users which may not be what you want.

11

How about this alternative?

Define a start page rule to direct the un authorised users (i.e., users who are not part of the roles) to a custom empty portlet. On load this portlet, programmatically hit the logout page (URL?method=logout) probably in javascript. This way, even though the users are ‘authenticated’, they will see only login page because of the round-trip. (login and then logout). Hope this helps.

Kind regards,
Raj

12

@Raj

Unfortunately, that is not a secure solution as it could be easily defeated by loading an address that doesn’t display the user’s start page after login. Also an attack client that isn’t using a real web browser could simply not run the javscript blocks or follow the redirects and establish a valid session.

The only secure solution is to block the request handling before or during authentication.

13

Hi,

We are presently researching the option of creating an AD ‘container,’ which matches the restriction group we’ve defined, as a base User DN for the allowed users.

I’ll let you what you’ve discovered.

Best Regards,

14

SOLVED. :smiley:

It was simple but the documentation was misleading…

We could not find a way to create a virtual AD container to be used as a base DN for the user search but there is another way:

in the definition of the Directory Service you have the section “Advanced Object Filters” and options “User Object Filter” and “Group Object
Filter”.

The problem is you that CANNOT USE A COMPLEX QUERY such as:


(&(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=EXAMPLE,DC=LOCAL)(memberOf=CN=D10927.BPMS_LOGIN,OU=Technical,OU=BPMS,OU=SECGRP,OU=APP,OU=ORG,DC=EXAMPLE,DC=LOCAL))

You have to simplify it to:


memberOf=CN=D10927.BPMS_LOGIN,OU=Technical,OU=BPMS,OU=SECGRP,OU=APP,OU=ORG,DC=EXAMPLE,DC=LOCAL

SO, no parenthesis, single expression.

The restriction to the object category person is assured by the User Attributes/User Object Class afterwards.

Thanks to all the people who contributed with suggestions. :slight_smile:

Happy hacking!

15

If there are areas that you or a customer would like to be improved in documentation or functionality, then you can make a proposal in brainstorm @ https://empower.softwareag.com/Products/FeatureRequestsInBrainstorm/default.asp for consideration in a future release.

16

Done.

Requests 04553 and 04554.