• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (8)

1 Lisa DeLuca commented Permalink

When exchanging the auth code for an access token I get the following curl error:

curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Using -k worked... just letting others know.

2 kranthi vallamreddy commented Permalink


I am new to this world of Security, i am trying to setup TFIM server with OAuth capability and found this interesting link,
I wanted to start from the beginning and i tried this " introduction article to the demonstration site" link, but that does not work(page opens with no information in it), can some one help me with his, did the link change or is there any other way to get to that link.

3 Shane Weeden commented Permalink

Kranthi - I am looking into it. Thanks, Shane.

4 Kalyan Kumar Saha commented Permalink

Hi Shane,

At first thanks for this wonderful article!!
I am trying similar thing using TFIM but facing issue during resource access.The protected resource is being accessed through java client (using HttpURLConnection) and it seems WebSEAL expects session cookie to be present in the request Cookie header along with other OAuth data to grant access. Since OAuth client and OAuth server are in different domain, the cookie is not available in Java client and hence failing with "DPWWA1506E Unknown HTTP authentication scheme".
The demo works fine if AJAX in place of Java code is used and I think that is because web browser automatically presents the cookie to WebSEAL while requesting protected resource.
Please advise.
Thanks & Regards,
Kalyan Kumar Saha

5 Shane Weeden commented Permalink

Kalyan - If you are using the EAS for authorization of resources, you should make sure that an unauthenticated-allowed ACL is attached to that object in the WebSEAL object space. OAuth resource server requests (when using the EAS) are not authenticated requests.

In the newer ISAM8/9 appliance platform we do have another mechanism for OAuth resource server enforcement called oauth-auth where the OAuth token is actually used as an authentication mechanism. This is not available with TFIM.
If you are interested in the ISAM 8/9 solutions, my colleague Phil Nye has written up quite a bit of information about it:
In the meantime, attach an unauth acl to your WebSEAL-protected OAuth resource, and allow the EAS to do authorization enforcement.

6 Kalyan Kumar Saha commented Permalink

Thanks Shane for your kind reply as always !!

As per your guidance, I did attach an unauthenticated ACL and now able to access resource using access_token. Previously I was relying upon "apply-tam-native-policy" property which got added during EAS configuration and the value was set to "false". If I understood the property correctly, TAM native ACL evaluation should not take effect. Please advise.
Also, would like to bring up an observation - If access_token is sent as Authorization header, the same issue (DPWWA1506E Unknown HTTP authentication scheme) prevails even after attaching unauthenticated ACL but if sent as query string, then resource is returned correctly.
My demo stack is ISAM 2.0. OAuth client is a Java web application hosted on Tomcat.
Thanks & Regards,
Kalyan Kumar Saha

7 Shane Weeden commented Permalink

My understanding is that apply-tam-native-policy is not applicable to the OAuth EAS. That setting is only applicable to context-based-access (RBA in TFIM) policy attachments.

I have definitely had the OAuth EAS working with ANY of Authorizaton header, POST body, or Query String methods of sending the access token. I strongly suspect there is a slight error in the request format, or the configuration.
The error message starting with DPWWA1506E makes me think you might have BA authentication enabled on the WebSEAL which is acting as the resource server. Don't do that.

8 Kalyan Kumar Saha commented Permalink

Thanks Shane for your kind reply!!

Since apply-tam-native-policy is related documentation comes under OAuth EAS stanza reference in IBM knowledge center, hence thought this is related to OAuth only but thank you for sharing the update with us that it is intended for TFIM RBA.
Yes, WebSEAL BA authentication was enabled. On disabling it, now Authorization header has also started working.
Thanks much Shane for your guidance and support all through!! :)

Add a Comment Add a Comment