Nested group based authorization

[VVK]

Experts,

 

Need your help with below requirement -

User authorization against nested AD group and sending the parent group details in Header response. In existing setup, I have access policy setup to check authorization against one AD group and have active expression to send out only that AD group name in custom header response. The code application end just look after that AD group name and do further authorization check in their own database to display appropriate pages to end user as per the role.

 

However lately we found that application team added few AD groups as member of parent AD group which is added in the access policy. Application team wants all users in nested group to have access to their application and they want us to send out the parent group name only(no code changes at their end). To address first requirement of nested group authorization, I enabled "Allow Nested groups" checkbox in allow access policy however it's not authorizing.

 

Can someone please help with solution to address this?

 

Thanks,
V

[Wellington Ferraz Adami]

Usually, checking "Allow Nested groups" on policy should be enough for az. Can you enable trace logs?

 

For the response, you can create the following and it'll return all nested groups associated to that user:

WebAgent-HTTP-Header-Variable
Type User Attribute
Response name: SM_NAMEIT
Attr Name=SM_USERNESTEDGROUPS

 

Don't forget to link the response to a rule.

You can also return only the groups names by adding a RegEx to the response (answered here: Regex Expression to select specific patterns )

 

Regards.

[Ujwol]

Did you flush the cache after making the Policy changes ?

[VVK]

I was able to resolve issue with Nested groups as AD groups were not created with proper scope.

 

However, I'm still unable to send the Parent group name details in HTTP Header response -

 

I have below expression to send the Header response - FILTER(GET('memberof'), 'CN=AppParentGroup_*')

 

I'm member of nested group and AppParentGroup is parent group. However, this is not giving my Parent group name in header response.

 

Can you please help me with it?

[Legacy User]

VVK

 

When we write expression, and it returns failure. Always take a step back and break the expression into singular functions.

 

Could you confirm if you see the Parent Group in this expression. Change your expression header response to...

 

GET('memberof').

 

This will return all the groups user is a memberof.  If here you don't see the Parent Group, then FILTER won't return any result. First lets debug this part and then work forward.

 

Regards

Hubert

[VVK]

Hi Hubert,

 

Yes, GET('memberof') is returning all AD groups which user is member of. I don't see a parent group as user is not directly member of it, but it's giving me nested group details. This makes sense.

 

I would like to know if we can configure a regular expression to know the parent group name only. The regular expression which I mentioned earlier works well when user is directly member of parent group. But with new requirement, user can be member of any nested group and if yes, then only parent group name needs to be returned in header response.

[Legacy User]

VVK

 

https://docops.ca.com/ca-single-sign-on/12-7/en/configuring/policy-server-configuration/responses-and-response-groups/ca-single-sign-on-generated-user-attributes

 

Based on the above, Could we try the following....

 

GET('SM_USERNESTEDGROUPS') - This should return the parent inaddition to the child.

 

If the above works, then lets try....

 

FILTER(GET('SM_USERNESTEDGROUPS'), 'CN=AppParentGroup_*')

 

 

Regards

Hubert

[VVK]

Thanks Hubert !

 

I tried it earlier to send SM_USERNESTEDGROUPS in HTTP header response but it doesn't return the Nested groups. It's more like of memberof giving the details groups to which user directly belongs to. I tried it one more time today, however same result.

We are currently running on R12.52 SP02 and CA bookshelf shows that this attribute is available with R12.52 releases.

 

 

FYI, AD group scope is set to Global. Do I need to check anything else?

[Legacy User]

VVK

 

Irrespective of the Product Version, both documentation and product functionality should be inline. SM_USERNESTEDGROUPS is a default CA SSO Header and has to be present in all versions of CA SSO.

 

I think there is a bug somewhere, either a bug in documentation OR a bug in the product. Presumably the latter.

 

I'd say it is a good time to raise a Support Case and clarify this with CA Engg; considering that you have confirmed that SM_USERNESTEDGROUPS is not returning the entire set as per what the documentation states.

 

When you do raise a support case, you can mention this blog in the case. Thus not needing to go through the entire process of explaining what steps were taken. I do however encourage to provide finer details of Versions / both high-level + trace logs (from WA and PS), in the support case. Paste only the case number here if you'd like to share.

 

Regards

Hubert

[VVK]

Last week, I opened a ticket with CA engineering team asking if there is any OOTB functionality available to send the Parent group name in header response when user belongs to nested group and here is the response I got yesterday -

 

"I presented your use case to a CA Services architect and you cannot achieve this function Out of The Box.  Let me know if you have further questions"

 

I always feel CA community is place to get appropriate solution rather than submitting a ticket.

 

[Legacy User]

VVK

 

What is the CA Support Case number?

[VVK]

00932869

[Legacy User]

VVK

 

It seems by feedback from Support you are receiving both ParentGroup and NestedGroup in the Response. If that is the case then we can use expression to filter.

 

Could you upload the following info to CA Support Case. Thank You.

 

• Could you confirm by screenshots
  • what has been configured on Response.
  • how nested group is setup in AD
• WebAgentTrace.log for the txn.
• Policy Server Trace log for the txn.

[VVK]

Hi Hubert,

 

Thanks for following up on this !

 

No. I'm still not getting the parent group details when I use SM_USERNESTEDGROUPS attribute. CA Engineer reproduced the issue with on lab server with same SMPS version and he is also not getting parent group name.

 

We are getting same response using attributes SM_USERNESTEDGROUPS & SM_USERGROUPS.

 

: 'SM_USERNESTEDGROUPS=cn=Parentgroup,ou=Netegrity,dc=nasa,dc=gov^cn=nestedgroup,cn=Parentgroup,ou=Netegrity,dc=nasa,dc=gov' -

: 'SM_USERGROUPS =cn=Parentgroup,ou=Netegrity,dc=nasa,dc=gov^cn=nestedgroup,cn=Parentgroup,ou=Netegrity,dc=nasa,dc=gov' - '

 

He'll opening up a defect with Engineering team.

[Legacy User]

VVK

 

https://support.ca.com/us/knowledge-base-articles.TEC490905.html

We cannot use both at the same time.

 

Can you quickly check in your ENV by just configuring SM_USERGROUPS what is returned and then configuring SM_USERNESTEDGROUPS.

 

Use one at a time and see the difference.

[VVK]

Well, I added both the responses in one policy so I can show it to CA support engineer. Earlier I configured these response separately and I was getting the same result. I tried one more time, but no luck. SMTESTTool returns same group list after configuring either or the user attribute.

[Legacy User]

Thank You Vishal VVK

 

Added note : In support lab

cn=Parentgroup,ou=Netegrity.... is the Parent Group.

cn=nestedgroup,cn=Parentgroup.... is the Nested Group.

We are receiving Parent Group and Nested Group even when using a single response i.e. either SM_USERGROUPS or SM_USERNESTEDGROUPS. So support is going to follow up with Engg on this anomaly.

 

The bottemline is the issue remains in your ENV "I'm still not getting the parent group details when I use SM_USERNESTEDGROUPS attribute". Highlighting this line, because I can mention this on the case.

 

Could you upload all these details to the case please as a single zip file.

 

• Could you confirm by screenshots
  • what has been configured on Responses in your policy.
  • SmTestTool result in a notepad (copy paste the result from SmTestTool).
  • how nested group is setup in AD. The entire structure.
• WebAgentTrace.log for the txn.
• Policy Server Trace log for the txn.
• Active Directory Version ?
• Policy Server Version R12.52 SP2.

[Legacy User]

Vishal VVK

 

Finally managed to get hands on my lab at the end of day (logged off my primary work network).

 

Here it is, what works for me. My Policy Server is R12.7 on Linux with CA Directory R12.5 SP01 on Linux as User Store.

 

 

SETUP IN LDAP / CADIR

 

Parent Group  [Contains a Group as a Member]

 

Nested Group  [Contains an User as a Member]

 

WITH SM_USERNESTEDGROUPS.

 

Using "userattr" and "expr" as Response

 

Test Result

 

Inference :

[1] SM_USERNESTEDGROUPS Works as per CA Documentation. Returns both Parent and Nested Group.

[2] Works with Expression returning only the Parent Group.

 

 

WITH SM_USERGROUPS.

 

Testing using SM_USERGROUPS

 

Inference :

[1] SM_USERGROUPS Works as per CA Documentation. Returns only the Nested Group i.e. the Group that user is memberof.

 

 

 

 

The next action, is to look at your AD group structure, configured responses, webagent traces and policy server traces.

 

 

Could you upload all these details to the case please as a single zip file.

 

• Could you confirm by screenshots
  • what has been configured on Responses in your policy.
  • SmTestTool result in a notepad (copy paste the result from SmTestTool).
  • how nested group is setup in AD. The entire structure.
• WebAgentTrace.log for the txn.
• Policy Server Trace log for the txn.
• Active Directory Version ?
• Policy Server Version R12.52 SP2.

 

 

Regards

Hubert

[VVK]

Thanks Hubert for your extended help ! Appreciate it!.

 

I uploaded requested details in case except Web Agent Trace logs as I couldn't get it from application team.

 

AD Schema version - 69

 

Please let me know if you need any additional details.

[VVK]

I did further troubleshooting on this issue and here is my analysis -

 

1. Application for which we want to pass parent+nested group details from AD in HTTP header is having CA directory as an authentication directory and AD as authorization directory. The auth/az mapping is setup using universal ID. Whenever we use SM_USERNESTEDGROUPS attribute in HTTP Header response, we are not getting the parent group details. It passes only group names which user is directly member of.

 

2. We can some other applications for which we are using AD as an authentication/authorization directory. I performed POC and passing the SM_USERNESTEDGROUPS attribute in HTTP Header response on successful authorization. To my surprise it's passing both parent & nested group details in HTTP header response.

 

To summarize, SM_USERNESTEDGROUPS attribute in HTTP Header response seems to be working fine when we have AD as an Auth & AZ directory and not in scenario where some other LDAP configured as Authentication directory and AD as an authorization with Auth/AZ mapping.

But in CA documentation, I don't see any such caveats.

 

Could you please help me in understanding why Auth/AZ mapping will cause an issue in this?

[Legacy User]

Thank You for the finer details Vishal VVK

 

The default SM Headers are populated based on Authentication Directory, we know that for a fact. Now what I am unsure is if SM_USERGROUPS and SM_USERNESTEDGROUPS also fall in purview of Authentication Directory only. There is a table at the end of this page, which does state that SM_USERNESTEDGROUPS is available on AccessAccept. When we are using Directory Mapping can we create a OnAccessAcceptRule and assign the response to OnAccessAcceptRule, then try.

 

Meanwhile, could you upload in Support Case an export of just the policy domain with directory mapping and responses configured. Just want to see if everything is configured correctly.

 

Regards

Hubert

[VVK]

As per the policy configuration guide for R12.52 version of SMPS -

 

 

SM_USERNESTEDGROUPS is available on all action events except OnAuthReject. In our setup, the response is mapped to GET/POST rule.

Is there anything changed on CA Support site? I'm continuously getting below error message while trying to open the support case opened with CA -

"We can't log you in. Check for an invalid assertion in the SAML Assertion Validator (available in Single Sign-On Settings) or check the login history for failed logins."

[Ujwol]

SM_USERGROUPS and SM_USERNESTEDGROUPS are computed only once after successful user authenticaiton.

It is NOT recomputed after user authorization.

That is the reason why it is also avaiable durign OnAccessReject.

 

So, yes SM_USERGROUPS and SM_USERNESTEDGROUPS are ALWAYS based on authenticaiton directory and not authorization directory.

 

 

 

[Legacy User]

I think lets take this discussion offline into CA Support Case and get back with a final answer.

 

VVK Vishal - I'll need you to carefully vet each word in the below Synopsis. It is crucial we understand exactly what you are seeing. I did see some disconnect from where we were in terms of understand your configuration & now where we are. Hence I need your help to scrutinize each word and correct the issue synopsis. Asking a question OR writing a synopsis is also an art (I learnt that from the best Rich_Faust and trying to improve) such that the other person understands. Hence I am going to rephrase your problem statement and your configuration.

 

 

Synopsis

Configuration Statement-1 : Authentication Directory = CA Dir and Authorization Directory = AD. So we are using Directory Mapping. My next question will be which Directory Mapping i.e. the one under Legacy OR Identity Mapping? Statement-2 : We only have a GET/POST Rule in the Realm. Statement-3 : The Realm has the Directory Mapping selected. Statement-4 : In the Users Tab in Policies there is nothing added under CA Directory, but under AD you have users OR groups OR members OR 'All' added. Also there is the GET/POST Rule added to this Policy. Statement-5 : When using SM_USERGROUPS only in Response, you are seeing the nested group (i.e. the Group the User is directly mapped to) returned from AD in SM_USERGROUPS. Statement-6 : When using SM_USERNESTEDGROUPS only in Response, you are seeing the nested group (i.e. the Group the User is directly mapped to) returned from AD in SM_USERNESTEDGROUPS.     Issue Statement When using a single directory as Authentication and Authorization directory (i.e. no Directory Mapping), SM_USERNESTEDGROUPS populates Parent Group and Nested Group. When using two user directories e.g. CA Directory as Authentication Directory and AD as Authorization Directory (i.e. with Directory Mapping), SM_USERNESTEDGROUPS is populated with only the Nested Group from Authorization Directory (i.e. AD).

[VVK]

Thanks Hubert !

 

Please see my comments inline -

 

Configuration

Statement-1 : Authentication Directory = CA Dir and Authorization Directory = AD. So we are using Directory Mapping. My next question will be which Directory Mapping i.e. the one under Legacy OR Identity Mapping?

<Vishal> We have Legacy Auth/AZ directory mapping configured for CA directory and AD on Universal ID. Universal ID configured for CA Directory is one of the attribute from user’s CA directory profile i.e. XID(used as SAMAccountName in AD) and SAMAccountName for AD.

Statement-2 : We only have a GET/POST Rule in the Realm.

<Vishal> In realm, we have below 2 rules configured–

1. GET/POST
2. OnAccessReject

Statement-3 : The Realm has the Directory Mapping selected.

<Vishal> Yes, Active Directory UD is selected under “Legacy Authorization Directory Mapping” in realm.

Statement-4 : In the Users Tab in Policies there is nothing added under CA Directory, but under AD you have users OR groups OR members OR 'All' added. Also there is the GET/POST Rule added to this Policy.

<Vishal> Yes, there is no filter added under CA Directory. For AD, parent group is added & “Allow Nested Groups” is selected to authorize users from nested groups. Yes, only GET/POST rules are added to this policy.

Statement-5 : When using SM_USERGROUPS only in Response, you are seeing the nested group (i.e. the Group the User is directly mapped to) returned from AD in SM_USERGROUPS.

<Vishal> Yes

Statement-6 : When using SM_USERNESTEDGROUPS only in Response, you are seeing the nested group (i.e. the Group the User is directly mapped to) returned from AD in SM_USERNESTEDGROUPS.

 <Vishal> Yes

 

Issue statement is correct.

Issue Statement

• When using a single directory as Authentication and Authorization directory (i.e. no Directory Mapping), SM_USERNESTEDGROUPS populates Parent Group and Nested Group.
• When using two user directories e.g. CA Directory as Authentication Directory and AD as Authorization Directory (i.e. with Directory Mapping), SM_USERNESTEDGROUPS is populated with only the Nested Group from Authorization Directory (i.e. AD).

 

Please let me know if you need any further details.

[Legacy User]

Thank You Vishal VVK for confirming the statement. I am going to update the CA Support Case for you. We'll get off this blog for a while and discuss over the CA Support Case. Whilst I'll not be in direct forefront of the Case, I'll channel the discussion for you, Support and Engg. Then let you folks take it forward from there. Once we have a final resolution, we'll update this blog. Thus no more discussion on SM_USERNESTEDGROUPS until resolution / clarity about Product functionality in CA Support Case.

 

I am also checking to see if I can get you an Alternative to SM_USERNESTEDGROUPS. We can discuss that here. I am not sure if you have a SMWALKER license. There is a function called WALKGROUPS in SMWALKER, which may also fit our purpose here. Now this would again be a question for GD (Global Delivery) Sid_Mautte if WALKGROUPS is supported in a Directory Mapping Model i.e. returns "member" i.e. both Parent Group and Nested Group from Az Directory.

 

Unfortunately I do not see WALKGROUPS in OOB CA SSO Expressions. It may be worth a blind shot to try.

 

SMWALKER

[VVK]

Thanks HubertDennis for your help in this !

 

Yes, I worked on SMALWKER tool but unfortunately we don't license for it. Please let me know if you find any alternative to cater to SM_USERNESTEDGROUPS requirement.

 

For the time being, I have figured out alternative to address application teams needs for their monthly release and they provided testing signoff. So we are good for time being.