New post
Question
· Mar 18, 2017

Password change on inbound web-services

#Beginner #Caché #SOAP #Security

We are planning to use Caché users on a SOAP web-service, so the WS-security tokens will be used.
It will be username and password only for now.
The passwords should expire on a regular basis and this will be configured in the system-wide security settings.
The consumer of the web-service should be able to change their password on-demand or when it has expired, via a web-service call.

For the on-demand change, I can create a service method which can be called by the consumer to change the password.

In the case of an expired password, I am unable to figure out how the password can be changed via a service call, once it has expired. There is an option for a Password Change Page on the CSP application configuration, but this will not work, as it is a system connecting to the service and not an end-user.
Does Caché provide a mechanism for password changes on the CSP application security for inbound web-services?

Any advice will be greatly appreciated.

Discussion (5)0
Log in or sign up to continue
Tony Beukes · Mar 25, 2017

You can use %SYSTEM.Security ChangePassword. 

Example:
Set tSC = $$$OK
Set tPasswordChanged = $system.Security.ChangePassword(pUsername,pNewPassword,pOldPassword,.tSC)  
 

Assuming a web client has previously been authenticated, and the web service method called post the password expiring returns a SOAP authentication fault:

The caller could catch the authentication fault and then assume that the password has expired,

call the password change web service method,

and then retry the original call again.      

1 0
Stefan Cronje · Mar 26, 2017

Thank you Tony.

This would mean that the password change service will have to be on a CSP application configuration which is unauthenticated by the underlying Cache web-service handler.

Another option may be to let the password never expire and perform peer certificate verification by issuing a certificate to the client and verifying it during the SSL/TLS handshake.
Is this possible in Cache on the CSP gateway in some way, on a User level or even on a CSP application configuration?

0 0
Amir Samary · Apr 2, 2017

Hi!

You don't actually need to configure a certificate on your Apache or even to encrypt the communication between Apache and the SuperServer with SSL/TLS.

You can create a CSP Application that is Unauthenticated and give it privileges to do whatever your web services need to do (Application Roles - more info here). I would also configure a "Permitted Classes" with a pattern to only allow your specific web services to be called. I would also block CSP/ZEN and DeepSee on this CSP Application.

More info on configuring CSP Applications here.

Then, for each web service you want to publish on this application (that is mentioned on the Permitted Classes), you will create a Web Service Security Policy using an existing Caché Studio wizard for that (more info here).

The wizard will allow you to choose from a set of options and several variations for each option on securing your web service. You may choose from the combobox "Mutual X.509 Certificates Security". Here is the description for this option:

This policy requires all peers to sign the message body and timestamp, as well as WS-Addressing headers, if included. It also optionally encrypts the message body with the public key of the peer's certificate.

You can configure Caché PKI (Public Key Infrastructure) to have your own CA (Certificate Authority) and generate the certificates that your server and clients will use.

This guarantees that only a client that has the certificate given by you will be able to authenticate and call this web service. The body of the call will be encrypted. 

If you restrict the entry points of this "Unauthenticated" csp application using "Permitted Classes" and if these permitted classes are web services protected by these policies, you are good to go. Remember to give to this application the privileges (Application Roles) for your service to be able to run properly (privilege on the database resource, SQL tables, etc.).

This doesn't require a username token. If you still want to use a username/password token, you can require that using the same wizard. Here is an additional description that the wizard provides:

Include Encrypted UsernameToken: This policy may optionally require the client to send a Username Token (with username and password). The Username Token must be specified at runtime. To specify the Username Token, set the Username and Password properties or add an instance of %SOAP.Security.UsernameToken to the Security header with the default $$$SOAPWSPasswordText type.

If you decide to do that, make sure your CSP application is configure for authentication  "Password" and do not check "Unauthenticated". 

Also, don't forget to use a real Apache web server. My point is that you don't need to configure your apache or its connection to the super server with a SSL certificate for all this to work. Caché will do the work, not Apache. Apache will receive a SOAP call that won't be totally encrypted. But If you look into it, you will notice that the body is encrypted, the header includes a signed timestamp, the username/password token will be encrypted, etc, etc. So, although this is not HTTPS, the certificates are being used to do all sort of things in the header and the body of the call that will give you a lot more protection that plain HTTPS.

But please, don't get me wrong. You need HTTPS if you are building an HTML web application or if you are using other kinds of web services such as REST, that don't have all the alternative enterprise security provided by SOAP. SOAP can stand alone, secure, without HTTPS. Your web application can't. 

1 0