Symantec Access Management

Hi All,

  We are implementing Oauth2.0 with one of our partner and using partnership model to establish OAuth SSO.

We are getting same error as mentioned in OAUTH Partnership Error Dispatcher object thrown unknown exception while processing the message 

SiteMinder Secure Proxy Server WebAgent, Version 12.52 QMR01, Update HF-02, Label 766

Policy server Version: 12.52; Update: 01.02; Build: 766; CR: 02;

[09/06/2016][10:02:37][3944][4076][395844d9-9479f77a-665fc3a6-415af154-2b617bac-bb][OAuth20Utils][sendClientMessage][Exception occured while sending an OAuth message:  Exception occurred while message dispatcher (srca) object trying to send SOAP request message to the SAML producer.]

The solution mentioned in the KB article to enable BackChannel with partner,  but I don't see option to enable backchannel while configuring OAuth Partnership.

Please suggest if I am missing something here.

Thank  You

Hi Richard,

I checked and can confirm there's no option to configure backchannel for OAuth Partnership.

Is it working accordingly if internet connection is allowed?

Hi wonsa03,

     That was my doubt, I can see in coming connections but connections going out is giving these errors I am working to get those connections open, but still I am not clear why we are seeing those certificate error? OAuth Partnership don't give options to import any certificates. I think this error should be more specific may be stating cannot connect or something like that.

Hi Richard,

According to the exception you mentioned in the initial post, that exception is related to the error sending OAuth message to the remote entity.

And yes, there's no certificate settings with the OAuth Partnership.

Hi Richard,

KB article is talking about, allow NAT or internet connection between SPS/WAOP and Partner.

What is your Partner ?

Also please check whether all the required certificates to connect Partner are imported into the policy store.

Thanks,

Sharan

Any suggestions for this what exactly is missing due to which I am getting this error?

[09/09/2016][21:13:49][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][FederationTunnelClient.java][getAllCAcerts][Tunnel result code: 1.]
[09/09/2016][21:13:50][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][FederationTunnelClient.java][getAllCAcerts][Number of CA certificates received:31]
[09/09/2016][21:13:50][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][FederationTunnelClient.java][getAllCAcerts][Subject DN of last certificate received: OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US]
[09/09/2016][21:13:50][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][FederationTunnelClient.java][getAllCAcerts][Number of CA certificates copied to output:31]
[09/09/2016][21:13:50][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][FWSBase.java][getAllCAcerts][Obtained CA certificates from policy server. Total Certs received: 31]
[09/09/2016][21:13:55][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][MessageDispatcher.java][dispatchMessage][Dispatcher object thrown unknown exception while processing the message. Message: Certificate not verified..]
[09/09/2016][21:13:55][1868][3148][4a19dddb-7ce4433d-4cdbd1d0-b6998920-a9448654-9][MessageDispatcher.java][dispatchMessage][Exception:
javax.net.ssl.SSLException: Certificate not verified.

at com.rsa.sslj.x.aG.b(Unknown Source)
at com.rsa.sslj.x.aG.a(Unknown Source)
at com.rsa.sslj.x.aG.a(Unknown Source)
at com.rsa.sslj.x.ap.c(Unknown Source)
at com.rsa.sslj.x.ap.a(Unknown Source)
at com.rsa.sslj.x.ap.i(Unknown Source)
at com.rsa.sslj.x.ap.h(Unknown Source)
at com.rsa.sslj.x.aR.startHandshake(Unknown Source)
at com.rsa.ssl.SSLSocket.getOutputStream(Unknown Source)
at com.netegrity.srca.connection.SSLHandler.startSession(SSLHandler.java:339)

When I run smkeytool -listcerts I see 38 certificates getting listed but as the above logs, only 31 certificates are getting listed out? 

I can confirm that We can connect to partner services.

Thank you.

Hi Richard,

Ensure that you have imported all default trusted Certificate Authority certificates to the certificated data store.

smkeytool -importDefaultCACerts 

HI Kelly,

    Thanks for the Suggestion, I Ran this command and output was all default certificates already exists, but this time it loaded 36 certificates Due to some reason I think I passed this error and now getting error related to SMAUTHREASON=48 , I think I know why this could be coming, I will resolve this error and post here about my findings.

Thank You

Hi wonsa03

     In SAML we create response as <@lib="smfedattrresponse" func="getAttributeValue" param=" 

Supply SAML Attributes as HTTP Headers - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation (Configure a Response to Send Attributes as HTTP Headers)

Is there is a way we can send HTTP header in case of OAuth? Because I am not seeing HTTP headers from SAML and response configuration for User Attributes is coming empty.

Any thoughts?

Thank you

Hi Richard,

For a SAML entity, the Policy Server can use HTTP headers to pass identity attributes from an assertion to a back-end application. A backend application can be a target application for single sign-on or a user provisioning application. The system passes these headers in an encrypted cookie.

The headers have the same name as the assertion attributes. For example, if the assertion attribute is "address", the application looks for the HTTP header "ADDRESS".

Assertion attributes are case-sensitive, but HTTP headers are not. The Policy Server cannot pass the same attributes that differ only by case sensitivity and then map them to HTTP headers. For example, the system cannot pass "address" and "Address" as headers at the same time. In general, do not use the attributes with the same names that are only different because of case sensitivity or format.

The following additional values are passed as headers:
NAMEID
FORMAT
AUTHNCONTEXT

Please follow below link to Configure HTTP Headers to Pass Assertion Data.
https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2052%20SP1-ENU/Bookshelf_Files/HTML/idocs/application-integration.html#o1904894

Thanks,

Sharan

Sharan,

    I understand how SAML passes the HTTP headers. My question is more specific to OAUTH, is there any documentation for processing HTTP headers for OAUTH, if yes please suggest

Thank you

Hi Richard,

Under OAuth Partnership >> Target Application, select "Persist Attributes" as Redirect Mode. This will enable Policy Server to store the attributes that are extracted from an assertion in the session store and Siteminder can supply the attributes as HTTP header variables.

Important! To see this option, enable the session store using the CA SiteMinder® Policy Server Management Console.

Note: If you select PersistAttributes but the assertion contains blank attributes, a value of NULL is written to the session store. The NULL value acts as a placeholder for the blank attribute and it is passed to any application using the attribute.

Hi wonsa03

       Actually I thought of it and I didn't saw persist attribute option for OAUTH, FYI, we have Session store enabled and we use Persist Attribute as Redirect Mode for SAML.

Is this option available in your setup? I checked on other envrionments also I don't see persist attribute option for OAUTH.

Hi Richard,

You are right. I just checked again and the "Persist Attribute" option isn't there.

However, if you have "Use Persistent Session" checked in step 3. SSO, you will have the option "Persist Claims to Session Store".  According to the documentation, this option allows the Policy Server to store attributes that are extracted from an assertion in the session store. The system can then supply the attributes as HTTP header variables.

 I have not tested this feature before, but it seems promising.

Hi Richard,

I'm having the same issue, how were you able to get around this error?

mjeanjacques, we created response for the domain which is acting as endpoint like:

USERNAME=<@lib="smfedattrresponse" func="getAttributeValue" param="SAMAccountname"@>

I hope that's the approach not suggested but it works for our environment. Hope that helps.