CA Service Management

Is it possible to use the external authentication process that web engine uses to access web services methods? I can see a SID being passed, but cannot use it. I assume that's because they are different systems within SDM. So is the same functionality possible for web services?

Hi James,

This question is currently posted under "CA Single Sign-On" category.

Are you sure this belongs to CA SSO?

Based on your question it does seem like belonging to SDM ?

Please confirm.

Regards,

Ujwol 

Hi,

Not sure what you are trying to do but the web service will use the authentication specified in the corresponding access type.

You first use the login method with your credential to receive an SID that you can use in all your sub-call during that session.

hope this help

/J

Thank you for your reply.

The statement

You first use the login method with your credential to receive an SID that you can use in all your sub-call during that session.

is what I am referring to. On the web client we have single sign on enabled (pardon if my verbiage is incorrect; I am translating from the admin and I am a developer). The user is not prompted for username and password. They are simply validated via windows authentication and taken to the main screen. I am trying to emulate this task for an application I am writing so credentials do not need to be entered to connect to the Web Services (SOAP API I believe).

Using fiddler when connecting to the web client I can see what appears to be a SID:

https://servicedesk.someserver.com/CAisd/pdmweb.exe?SID={SID visible here}+FID={FID visible here}+OP=REPLACE_LOGIN+HTMPL=post_menu.htmpl

so I know the web page is authenticating without credentials. I am trying to do the same in Web Services. I have tried to grab the SID shown by making an HTTP request and I can receive the SID, but I cannot appear to do anything with it.

Hope I clarified a bit better. 

yep thanks for the clarification.

The above  don't mean that the web page don't authenticate but just that the authentication has been delegated to the SSO mechanism (mostlyusing REMOTE_USER). Note also that this is 2 different app and they don't share session id.

You can connect to the web interface from a pre eablished session in the web services using the getBopsid method but you can't do the reverse way.

Up to my knowledge your way will not be directly possible with the SOAP web services where the authentication need to be process by the method to obtain the SID.

May you don't want to pass those credentials to the method you then better use certificate base authentication using the loginServiceManaged method. This is in fact recommended and more secure.

When after authentication you have the need to operate in the context of a specific user you can then use the impersonate method to receive the corresponding SID

Hope this help.

/J

Thank you very much for your response.

That's what I was afraid of. Hopefully sometime in the future the SSO mechanism will be able to be used for the SOAP web services. Unfortunately the certificate based authentication is not going to be activated so I am stuck there. Looks like my users still get to enter credentials 

Thanks again and I will mark your response as the answer.

well if you explain me a little more what you try to accomplish and your context we may find a solution.

as I say you can use the impersonate method to run in the context of the user.

so we can use a service account to logon to the web services.

get the userid from the logged in userid from the web interface and the use it to impersonate.

all the subsequent web service call will then be done on the behalf of this user.

/J 

The context is we have an IT department that received hundreds of calls a day from the business. They have many different systems they must interact with including AD, Exchange, and CA SDM. Instead of having a ton of different windows open it was requested that we write an ASP .Net application to tie in as many systems as possible so our phone takers can simply enter a little information and have the rest automated for them. So far it has been well received, but they must enter their CA credentials at the start of the session (and again if the session expires).

When we first started looking into interacting with the ticketing system it was determined that the SOAP API would best fit our needs. So that was used to automate things such as ticket creation, user lookup and more. So far it has covered all of the bases and works well in C#. We wrote a class library around it to simplify it further.

Recently the SDM system was upgraded to 14.1 and SSO was enabled. Now the ticketing system is very easy to get into and my users are requesting the same ability using our custom application (which also has SSO so we have the information of the user). Unfortunately I have been unable to find a way to do it. I have seen that certification-based authentication is possible, but our company gets very worries when the word "impersonate" is used. Our security department is very strict on how the systems are allowed to be used. I may revisit the loginServiceManaged method and see if I can get traction as this is the only way I see us able to move forward.

If you do have any other ideas I would love to hear them. I am not opposed to doing some wacky ways to make it work (hence the web request to get a SID to use for SOAP) but I cannot find any other solutions.

in fact we did some similar with full home made portal in ASP running on IIS.

The difference been we used RESTFull web service vs. SOAP in the backend as this is faster and more lightweight for such purpose but principle remain the same.

Both SDM and our portal have transparent logon using IIS integrated authentication.

In your case I only see the use of the impersonate  to fix your problem.

Security wise this is secure as soon you correctly handle the way you receive and control the userid to be passed upfront.

So the security here completely rely of the robustness of your ASP code.

Hope this help

/J

Very much so, thanks!

In digging a little further with the impersonation I don't see where this would open us up to any further damage than what could already happen now. Since the impersonation cannot go any higher than the policy set to the service account, it would be no different than obtaining the user's username and password which would be a much larger problem anyway.

I have notified our security office with all the technical documentation and a summary of what we are attempting to accomplish. I thank you again for all your help. You have clarified much for me.

I sill still keep the answer that is currently marked as that does answer the question. But this thread is most helpful on other ways to proceed. Thanks again!