Symantec Access Management

Hi,

I am trying to add a customer header using WebAgent-HTTP-Header-Variable.

We have successfully used WebAgent-HTTP-Cookie-Variable, but can't get WebAgent-HTTP-Header-Variable to work.  I am setting up the header variables in the same response group as the cookie responses.  All of the cookie responses work fine, but I can't get any new headers to show.  I have tried adding a simple static header of "testing=1".  All of the standard Siteminder headers are working correctly.

Any idea what I may be missing?

thanks

chad

Chad

Have the policy server profiler log configured to the below (assuming your user store is LDAP).

components: AgentFunc/Init, AgentFunc/UnInit, AgentFunc/IsProtected, AgentFunc/Login, AgentFunc/ChangePassword, AgentFunc/Validate, AgentFunc/Logout, AgentFunc/Authorize, Server/Policy_Server_General, IsProtected, Login_Logout, IsAuthorized, Tunnel_Service, JavaAPI, Directory_Access, ODBC/Sql_Statement_Begin_End, ODBC/Connection_Management, ODBC/Sql_Errors, ODBC/Connection_Monitor, LDAP/Ldap_Call_Begin_End, LDAP/Internal_Operation, LDAP/Ldap_Error_Messages

data: Date, PreciseTime, SrcFile, Function, TransactionName, Message, Data, AgentName, Resource, User, Group, Realm, Domain, Directory, Policy, Rule, ActiveExpr, Expression, ErrorValue, ReturnValue, ErrorString, IPAddr, IPPort, Result, Returns, CallDetail, AuthScheme, AuthReason, AuthStatus

version: 1.1

You should be able to see what responses the policy server is processing.

[08/17/2015][19:21:32.114][SmAuthorization.cpp:1545][CSmAz::IsOk][][Check the Policy.][][][][][][][pd_application1][][pd_application1_acceptPolicy][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.114][SmAuthorization.cpp:1588][CSmAz::IsOk][][Check the Rule][][][][][][][pd_application1][][][pd_application1_rule][][][][][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:666][CSmAz::TestRule][][Enter function CSmAz::TestRule][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:771][CSmAz::TestRule][][Leave function CSmAz::TestRule][][][][][][][][][][][][][][true][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:778][CSmAz::TestPolicy][][Enter function CSmAz::TestPolicy][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:797][CSmAz::TestPolicy][][Evaluating policy...][][][][][][][pd_application1][][pd_application1_acceptPolicy][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:1214][CSmAz::TestPolicy][][Leave function CSmAz::TestPolicy][][][][][][][][][][][][][][true][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:1748][CSmAz::IsOk][][Policy is applicable. Rule is applicable. Get Responses.][][][][][][][pd_application1][][pd_application1_acceptPolicy][pd_application1_rule][][][][][][][][][][][][][]

[08/17/2015][19:21:32.115][SmAuthorization.cpp:1935][CSmAz::Process_Response_List][][Enter function CSmAz::Process_Response_List][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.137][SmAuthorization.cpp:304][CSmAzRespAttr][][Enter function CSmAzRespAttr][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.137][SmActiveExpr.cpp:501][CSmActiveExpr::GetActiveValue][][Enter function CSmActiveExpr::GetActiveValue][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.137][SmAuthUser.cpp:2182][CSmAuthUser::GetPropIndex][][Enter function CSmAuthUser::GetPropIndex][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.137][SmAuthUser.cpp:2213][GetPropIndex][][Processing Attribute [Property = mail] [Trim Property = mail] [Separator = ^]][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.137][SmDsAliases.cpp:578][CSmDsAliases::IsSpecialAttrMapping][][Enter function CSmDsAliases::IsSpecialAttrMapping][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.137][SmDsAliases.cpp:428][CSmDsAliases::GetAttributeMapping][][Enter function CSmDsAliases::GetAttributeMapping][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsAliases.cpp:435][CSmDsAliases::GetAttributeMapping][][Leave function CSmDsAliases::GetAttributeMapping][][][][][][][][][][][][][][false][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsAliases.cpp:586][CSmDsAliases::IsSpecialAttrMapping][][Leave function CSmDsAliases::IsSpecialAttrMapping][][][][][][][][][][][][][][false][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsObj.cpp:94][CSmDsObj::IsValid][][Start of call IsValid.][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsObj.cpp:96][CSmDsObj::IsValid][][Return from call IsValid.][][][][][][][][][][][][][][true][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsAliases.cpp:554][CSmDsAliases::GetAttributeNameFromAlias][][Enter function CSmDsAliases::GetAttributeNameFromAlias][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsAliases.cpp:428][CSmDsAliases::GetAttributeMapping][][Enter function CSmDsAliases::GetAttributeMapping][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsAliases.cpp:435][CSmDsAliases::GetAttributeMapping][][Leave function CSmDsAliases::GetAttributeMapping][][][][][][][][][][][][][][false][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsAliases.cpp:559][CSmDsAliases::GetAttributeNameFromAlias][][Leave function CSmDsAliases::GetAttributeNameFromAlias][][][][][][][][][][][][][][true][][][][][][][][][]

[08/17/2015][19:21:32.138][SmDsUser.cpp:403][GetProp][][Property 'mail' for user 'cn=AAAAAA,ou=OrgUnit0,dc=ca,dc=com' found in cache][][][][][][][][][][][][][][][][][][][][][][][]

[08/17/2015][19:21:32.139][SmAuthUser.cpp:2514][CSmAuthUser::GetPropIndex][][Leave function CSmAuthUser::GetPropIndex][][][][][][][][][][][][][][true][][][][][][][][][]

[08/17/2015][19:21:32.139][SmActiveExpr.cpp:520][CSmActiveExprLibrary::GetActiveValue][][Leave function CSmActiveExprLibrary::GetActiveValue][][][][][][][][][][][][][][pd_reg_mail=AAAAAA@dc=ca,dc=com][][][][][][][][][]

[08/17/2015][19:21:32.139][SmAuthorization.cpp:411][CSmAzRespAttr][][Leave function CSmAzRespAttr][][][][][][][][][][][][][][ok][][][][][][][][][]

[08/17/2015][19:21:32.139][SmAuthorization.cpp:2198][CSmAz::Process_Response_List][][Leave function CSmAz::Process_Response_List][][][][][][][][][][][][][][true][][][][][][][][][]

Regards

Hubert

I would also recommend using a SMTEST Tool to check it against the Policy Server, rather than debug this at WA end.

Regards

Hubert

I am using SQL server as the data store.  My custom header is named "testid".  I looked at the policy server logs, and it appears to be setting the header in the logs. 

[08/20/2015][09:22:50.259][09:22:50][15967][3206126448][SmDsUser.cpp:385][GetProp][][][][][][][][][][][][][][][][][][][][][Property 'n19_cst_id' for user '8057504' found in cache]

[08/20/2015][09:22:50.259][09:22:50][15967][3206126448][SmActiveExpr.cpp:520][CSmActiveExprLibrary::GetActiveValue][][][][][][][][][][][][][testid=8057504][][][][][][][][Leave function CSmActiveExprLibrary::GetActiveValue]

My set up is:

My perl script to display the variables shows all of the default Siteminder headers, but doesn't show my "testid" header.  All of the custom cookies work though.

The script is:

#!/usr/bin/perl

use CGI qw(:standard);

print CGI::header();

foreach ( keys %ENV) {

print "<P> $_ = " . $ENV{$_} ."</P>";

}

I got it to work sort of.  If I go into the policy and add a response to a specific rule, the header now shows up.

But I thought that Global Responses would run for rules?   Is that not the case?  Do I have to set a response for each rule?  My set has over 100 rules rules and I was hoping I could set one Global Response that would fire on each rule.

Just tested this with one Global Rule (with 2 header i.e. static and userattrb); attached to a normal rule. SMTestTool worked and spewed out the headers correctly from global response.

Regards

Hubert

am probably guessing it the rule set (are you creating rule groups) mapping to global response, may be causing this. Probably need to revisit the rule-set to global response mapping.

Regards

Hubert

That was it!  I had a global rule for On Auth accept.  So my Global responses only were fired when the user first logged in.  I created a new Global rule for on on access accept and that did the trick.  Thank you!

Dennis,

A quick follow up question.  I created a global OnAccessAccept rule.  Now my headers are correctly showing up on all protected content.  For content that is not covered by a Realm, the default Siteminder headers show but, the custom headers do not. 

For example lets say I have two perl scripts.

1.  mydomain.com/cgi-bin/show_all_headers.pl (This url is protected by a Realm)

2.  mydomain.com/cgi-bin/show_all_headers2.pl (This url is not covered by a Realm)

In the first both my customer headers and default Siteminder headers show up.

In the second, only the default Siteminder headers show.

Is there a rule I could set that would allow the custom headers to show up on urls that are not protected by a Realm?  I don't have  a use case for this now, but may in the future. 

Thank you again for the help.

One way I've used, and directed by CA Support to do this way, for 'non-protected' resources to get headers it to give them the Anonymous auth scheme. So if a non-authenticated user goes to the page they get access but no custom headers since unauthenticated. However, when a user has logged in previously and goes there the headers will fire since they have a session.

Others might have a different way, but that's worked for us in cases where that scenario was needed. Would be nice if there was a simple configuration to say to send headers if the user has a session even when 'unprotected' like other apps do (e.g., OpenAM).

Chad

As per current design of CA SSO / SiteMinder.

1. If user has a valid SMSession on the Browser. On unprotected resources, User would be able to see Only Default SiteMinder Headers. User would not have access to Headers being passed by Responses. Remember the WebAgent is only a PEP (Policy Enforcement Point) and Policy Server is PDP (Policy Decision Point). If a Resource is defined as unprotected within Policy Server OR is not defined within Policy Server; it is evaluated as an unprotected resource by Policy Server. This is then communicated to WebAgent. WebAgent simply ignores these resources if the IsProtected() API call returns unprotected from WebAgent Cache or from Policy Server. Therefore there is no Reponse Headers. To put it in other terms, it is as good as SiteMinder isn't there intercepting / challenging / validating.
2. If a realm is unprotected. If we add a rule under this unprotected realm and map that to a response i.e. technically we created a policy for unprotected resource. This now becomes a protected resource by siteminder. Therefore even though the realm is unprotected, adding the rule to a policy invariably makes the resource protected and user would be challenged by the authentication scheme defined in unprotected realm.

A hack would be to embedded a protected content within the unprotected resource. This protected content could be

• A small image on page (Remember to set OverrideIgnoreExtnFilter ACO parameter as images are defined to be Ignored using IgnoreExtn.
  • Help Prevent Attacks - CA SiteMinder® - 12.52 SP1 - CA Wiki
• A protected widget.

Also Chris has suggested one approach using Anonymous Authentication Scheme which you could try.

Regards

Hubert

@Chad_Phillips

Could you explain how are you verifying the header variables?

The HTTP headers doesn't show up in the HTTP headers monitoring tool like Fiddler.

Best way to verify is using SmTest tool as explained by Hubert.

Regards,

Ujwol Shrestha

I have a perl script on the server that displays back all the header variables.  All of the default Siteminder headers show up just fine.  Only the custom ones do not show.

I, too, was seeing cookie variables and not header variables.  Like you, I am displaying all header variables with a PERL script.  My configuration is different in that I specified a single response with multiple attributes, and that response is tied to an OnAuthAccept resource (I'm using the Application model rather than the Domain model).  I solved my 'invisible header variables' problem by lending credence to this snippet from the documentation:

HTTP Header and Cookie-Variables

Be aware that in a Web application environment, the HTTP-Header-Variable response attribute appears as an HTTP_attribute_name variable, where attribute_name is the name of the HTTP variable, for example USERFULLNAME. You do not have to have an underscore in the name as the underscores cause problems with some application servers.

Note: The server may convert any dash in the attribute name to an underscore (_), and all alphabetic characters to uppercase.

My headers were invisible because I had named them in the format UNDERSCORES_ADDED_FOR_LEGIBILITY.  I changed the variable names in the policy configuration to DASHES-ADDED-FOR-LEGIBILITY.  Per the note above, my PERL script now displays the header variable as DASHES_ADDED_FOR_LEGIBILITY (dashes replaced by underscores).

For reference, I'm running CA SSO r12.7 on CentOS 7.4 with Apache 2.4.29.