SPS configuration for Web Services

I'm sure I'm missing something. Hoping someone could point me to the error.

I have my SPS configured and enabled authentication and authorization web service. First question.

- Just having the SPS installed and auth az enabled, is that all we need to do to expose the REST and SOAP API? Or is there additional apps that I need to develop and deploy somewhere?

I have the app enabled in server.conf.

I've added a virtual host in the server.conf and pointed it to the webservicesagent/WebAgent.conf. From the logs, i can see that the web services initialized successfully. I can see the web agent initialized successfully.

I've created a test agent and tied that in the ACO. and I protected /authaz context with a x.509 authentication scheme.

When I try to get to the WSDL, i get a 500 server error. The only error I see is in the agenttrace.log, it enters the virtual host, and then throws a 500 error. Doesn't give me any other information.

No need to protect the AuthAzWS URL i.e. /authazws/auth for testing purposes. In Prodn we need to protect this using X509 auth.

Now in the ACO which we are using for AuthAzWS i.e. authaz_aco. Look at the AgentName Parameter. It is wa_authaz_app1,app1

Create a Policy Domain with a realm, with Basic Authentication Scheme, to protect resource /testpage, with rule /* (with GET POST PUT) and associate wa_authaz_app1 to this realm. Add the rule to Policy and allow all users for now.

I state this probable because even this gets enabled from SPS UI. If not then do manually.

Confirmed Mistake number-2.

I've added a virtual host in the server.conf and pointed it to the webservicesagent/WebAgent.conf. From the logs, i can see that the web services initialized successfully. I can see the web agent initialized successfully.

I state this confirmed, because I did the same blunder. Then scratched my head for a long time. Then figured out that when I enable the AuthAz App via the SPS UI, it creates a Virtual Host. That is the correct one. I did this via SPS UI, which created a VH for me automatically and it then worked like a smoothie.

Point number - 2 is very deceiving; it may lead us to believe to create a VH first and then enter the name of that VH here. It is actually the other way round. Enter a name which you would like your Virtual Host to be named as when, the SPS UI creates it for you.

Make sure what ever VH name you provide, it is a valid one e.g. resolves to an IP Address. If it is your play pen env, then make a host entry before you add the VH name in the SPS UI.

Enable the Web Services

Use the ACO that you created in the previous procedure to enable the web services through Administrative UI.

Icon

Note: If the values of enableauth and enableaz are set to no, the web services do not function even though you enable the support through CA SiteMinder® SPS Admin UI.

Follow these steps:

Navigate to Proxy Configuration, Auth and Az Web Services.

Type the unique host name of the web services virtual host in Host Name.

Type the name of the ACO that is created for the web services in Agent Configuration Object.

My AuthAzWS does not throw any errors. Therefore I am good from initiatlization perspective.

However something weird, SOAP UI says my resource /app1* is unprotected (I have a realm protecting /app1* with Basic Auth Scheme). So I am close, however I guess I am missing something small. The funny part is I don't see any traffic hitting policy server for the /app1 request. So I need to debug further, would see if I could gather more time.

AuthAzWS.log (DEBUG mode, By default authaz-log4j.xml has INFO, changed it to DEBUG and recycled the SPS Services).

No need to protect the AuthAzWS URL i.e. /authazws/auth for testing purposes. In Prodn we need to protect this using X509 auth.

Now in the ACO which we are using for AuthAzWS i.e. authaz_aco. Look at the AgentName Parameter. It is wa_authaz_app1,app1

Create a Policy Domain with a realm, with Basic Authentication Scheme, to protect resource /testpage, with rule /* (with GET POST PUT) and associate wa_authaz_app1 to this realm. Add the rule to Policy and allow all users for now.

I am stuck with this. My authaz.log shows pretty much the same log as above when I try to use the rest login against /app . I don't see my ws-agent hitting the policy server in smaccess.log on the policy sever, is that normal or a sign of a misconfiguration?

Just a couple general things I've found from our user of SPS AuthN/AuthZ web services

The application object you are using as the 'web service' can use a normal FORMS or RSA auth scheme.

Simply adding our already existing RSA authentication scheme to an application object allowed the web service to pass the PIN+TokenCode as the password value to do two-factor authentication

If you want the sessiontoken value created by the SPS Web Service to work as an SMSESSION cookie for a Web Agent, you must update the Web Agent ACO for "AcceptTPCookie=yes" . Now if you use the Web Service created token against that Web Agent it should work (assuming authlevel and ssozone are same of course).

Have not gotten the other direction working yet for Web Agent token --> SPS unfortunately

You can return custom attributes by simply adding them as normal header variables on the application object.

For exmaple, I add http header variable for myapp_username. The Web Service will return:

<response>

<name>myapp_username</name>

<value>testuser001</value>

</response>

Should work with any header variable, at least has for us so far including appending values together etc. Such as taking "username" + @ + "location"

It looks like you resolved the other issue of using SESSION generated by AuthAzWS and SSO to Standard WebAgents by setting AcceptTPCookie. Does it work the other way too i.e. an SMSession generated from standard WebAgent and use that in AuthAzWS Request?

Unfortunately the other way not working yet. We're working with CA Support on it; they're the ones that identified the AcceptTPCookie setting since it's using the SDK essentially to create the session.

If a solution is found will definitely post it out here for everyone. At least for us that's definitely the more useful case if Web Agent session --> AuthAzWs so passing tokens from front-end web apps to downstream services etc allows authn/authz on behalf of some user.

Thank You Chris, meanwhile am going to paste the reference thread for Session Cookie SSO here. As I have pointed CA Tech Documentation Team to this thread to when they revise the AuthAzWS Documentation (WiKi) "You too have a comment on the WiKi".

I'm also working on SPS / Restful integration. Was wondering if you can help. First, do we need to setup 2 ACOs to support Restful - it can not go threw the proxyrules.xml? Which means I need to set another VH to support Restful URL... And can you or someone post a Restful XML file (contents) to assist in testing..

Also if this does not help, please open a new thread as this thread is now getting claustrophobic due to the piling on queries. In the new thread, we could reference this discussion as a hyperlink and also TAG people for their attention.

Thanks for getting back to me on this... I took the advanced and used WDSL xml file to use as a template and updated it with login id/password, etc info... I'm using SoapUI (non-pro) to do my testing for now.

I do have a question(s) that I hope you can answer.

Based on the docs and articles, it appears that setting up webservices on a SPS server - and we do not use proxyrules.mxl - that you just set the VH in server.conf file with assigned webagent.conf. If this is the case, my questions are;

How do you setup multiple web services with different VH ?

When setting up the URI that the user is trying to access - where do you store the pages? on the SPS server(s)? Unclear where you setup your pages(site) to use webservices feature?

Also, as far as the client program for webservices - any suggestion on the best practice to use to create one?

Hubert : The AuthAzWS is an interface (in SOAP and REST form) we provide for Authentication and Authorization decision to be leveraged using a SOAP / REST call be consuming apps which need authentication OR authorization decisions to be made. Hence there would be always only one single AuthAzWS VH, there would not be another AuthAzWS VH on the same SPS. THe whole purpose we built this feature is to only support Authentication and Authorization decisions via a SOAP / REST call. This VH does not serve any other purpose.

Q : When setting up the URI that the user is trying to access - where do you store the pages? on the SPS server(s)? Unclear where you setup your pages(site) to use webservices feature?

Hubert : There are no pages deployed on AuthAzWS VH. We just make a SOAP / REST call for Authentication and Authorization decisions. Based on the SOAP / REST Response this WS / VH provides to the client making the call; the client can further process the request at their end.

Q : Also, as far as the client program for webservices - any suggestion on the best practice to use to create one?

Hubert : The core structure / format of call is provided by the WSDL. In scope of the client program making a call to AuthAzWS. We would need to secure that call. We do have a few good discussions on communities which elaborates securing the AuthAzWS call.

I have to thank you again for answering my questions and helping me understand more on how this web services functions. I will check on the discussion group per your suggestion....Thank you again - really appreciate it.. Have a great weekend... Talk to you later...

I was away last couple of weeks...Is your issue resolved? I am still not able to protect webservices I can see web services and the web agent are initialized. I have a sample application on different server I want to call that app with webservices Can you please advice me how I have to configure?

I am assuming we shipped AuthAz feature in R12.52 SP1. I need to dig into details. However the simpler way is if we navigate to <secure-proxy-home>/Tomcat/webapps folder you would see the authaz webservices folder. If is is not present in R12.52 base version, that confirms the understanding.

Is there any reason that stops you from using R12.52 SP1 (unless you already have R12.52 base version and are on second thoughts on upgrading).

NOTE : Please open a new thread for new queries, as it help save unnecessary clutter and keeps a thread specific to a discussion.

We see AuthAZ webservices under <secure-proxy-home>/Tomcat/webapps on SPS 12.52. the official version should go on SPS12.52, we have configured in the similar way on both SPS versions, still see the issue, and testing through SOAP UI.