Symantec Access Management

Do we have a workaround to evaluate a siteminder rule with string containing query parameters  if igonrequeryparameter is set to YES ?

My scenario explained below:-

In BT infrastructure we have igonrequeryparameter is set to YES.

I have two different realms.

Realm1/rule1 with /abc?target=xyz and authscheme1

Realm2/rule2 with /abc  and authscheme2.

I have respective * rules and policies for both realms.

My requirement: When I access <DNS>/abc?target=xyz Realm1/rule1 should be triggered as that is the longest/best match string here. But as igonrequeryparameter is set to YES I still see Realm2/rule2  with authscheme2 getting triggered. 

Do we have workaround solution to achieve my requirement as explained above ?

Both Yes/No answer are welcomed, so that we can move forward on this and try to implement our requirement in some other way.

Thanks,

soumya Ranjan 

Hi

When you refer to "igonrequeryparameter" do you mean "IgnoreQueryData"?  If so, as explained here:Ignore Unprotected Resources - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation  you are seeing expected behaviour.

You don't say why this parameter is set to yes: if it is set for performance reasons turning it to "NO" would resolve the problem, but potentially impact performance.

The only "nice" solution I can think of would be if you could somehow direct traffic for <DNS>/abc?target=xyz to a different web server with a different ACO than everything else (for example if you had a load balancer that could do this.)

Regards

David 

Hi David,

Yes indeed it is  "IgnoreQueryDat". We have a common set up infrastructure in BT and adding new one is little difficult. Do you think of any other workaround/solution ?

Thanks,

soumya

Hi

I am afraid I can't think of anything, as the whole point of the parameter is to stop the policy server having to deal with the query strings.

Perhaps you could write some sort of custom auth scheme to replace both authschemes and dynamically behave in the required manner?  (just a thought: you would need to talk to someone with more knowledge of custom auth schemes to review your in depth requirements.)

Cheers

Also - is local config available to you as an option?

The best solution would be to raise an ER.

E.g. 

IgnoreExtn can be overridden by another ACO Parameter i.e. OverrideIgnoreExtnFilter

Similarly seek for a new ACO parameter i.e. OverrideIgnoreQueryData which overrides IgnoreQueryData - thus providing a flexibility within the product to IgnoreAllQueryData with the exception of a few specific ones. It is a good feature to have.

Regards

Hubert

I like this idea