more secure web services

[Kenji Watanabe, geändert vor 8 Jahren.]

Hi,

What is best approach to achieve more secure web services?
I need to accept encrypted credentials to decrypt locally before authentication.
Restricted IP and credential validation is not enoug for me.

Is this possible with authentication digest?
Do I have to set up custom authentication in properties, or do I have to write a custom Authentication Verifier?
Is see Jaas has encrypted password option.

Is there no ws* security with xmlencryption implementation in Liferay available?

Where can I find more explanation on this issue?

Thank you so much

[Tomas Polesovsky, geändert vor 8 Jahren.]

Hi Kenji,

Kenji Watanabe:

What is best approach to achieve more secure web services?

What kind of web services do you have - SOAP / JSON / REST?

Do you mean portal services or your own services in a plugin? Do you mean services generated by ServiceBuilder?

What is your current level of security, for example:
- do you use HTTPS?
- do you use HTTP Basic Auth?

Kenji Watanabe:

I need to accept encrypted credentials to decrypt locally before authentication.
Restricted IP and credential validation is not enoug for me.

Is this possible with authentication digest?

How do you receive these credentials? Inside request body or headers? It's a request parameter or insida SOAP header / body ?

Kenji Watanabe:

Do I have to set up custom authentication in properties, or do I have to write a custom Authentication Verifier?

Custom AuthVerifier should help.

Kenji Watanabe:

Is see Jaas has encrypted password option.

Which option do you mean?

Kenji Watanabe:

Is there no ws* security with xmlencryption implementation in Liferay available?

Not in <= 6.2. We use Axis1 to avoid conflicts with app servers WS-* libraries.

In 7.0 it should be possible.

Thanks.

[Kenji Watanabe, geändert vor 8 Jahren.]

Hi Tomas,

Thank you for your reply.

I have meant custom plugin JSON web services.
My current level is HTTPS Basic Auth for Liferay 6.1 GA3 portal.

I have succesfully tested credentials in request body but I gues this is not secure enough because credentials could be snooped when traffic is sniffed.
What I understand is that for start best is to send credentials once and then work with token.
This is what auth_digest seems to do with a nonce token but this way only the password can be encrypted.
As I understand from here you can use digest for web services while keeping default Liferay (basic) JAAS authentication for overall portal, am I right?

Tomas Polesovsky:

Custom AuthVerifier should help.

You mean writing custom Authenticator implementing com.liferay.portal.security.auth.Authenticator?

Kenji Watanabe:

Is there no ws* security with xmlencryption implementation in Liferay available?

Tomas Polesovsky:

Not in <= 6.2. We use Axis1 to avoid conflicts with app servers WS-* libraries.
In 7.0 it should be possible.
.

That would be very useful but in the meantime I need a way to encrypt (at least partially) credentials for web service calls.
I understand you suggest to write custom verifier to enable full credential encryption?

Thank you very much,

Regard,

Kenji

[Tomas Polesovsky, geändert vor 8 Jahren.]

Hi Kenji,

Kenji Watanabe:

My current level is HTTPS Basic Auth for Liferay 6.1 GA3 portal.

Oh, this is a bit outdated version. I strongly recommend updating to the latest stable CE version. Not only because in 6.1 GA3 it's much harder to implement a new authentication mechanism, but also there are several known vulnerabilities reported. Please see https://dev.liferay.com/web/community-security-team

Kenji Watanabe:

I have succesfully tested credentials in request body but I gues this is not secure enough because credentials could be snooped when traffic is sniffed.
What I understand is that for start best is to send credentials once and then work with token.
This is what auth_digest seems to do with a nonce token but this way only the password can be encrypted.

Well, to be pedantic, it's not exactly this way. HTTP Digest auth is not sending tokens as they are understood nowadays. It's sending a MD5 signature of important data used in the request. Anyways, it's much secure then HTTP Basic auth in case there is no transport encryption employed.

Here I'd strongly suggest to use HTTPS. Even self-signed certificate should be fine.

All you need is to configure your web/app server.

Then route all your remote API consumer calls (remote client calls) through the HTTPS endpoint. Make sure to validate the certificate on the client side.

Then you don't need HTTP Digest. HTTP Basic auth over HTTPS have the same level of security as Digest.

Btw. browsers don't need to know there is some HTTPS endpoint running on some port with a self-signed cert.

Kenji Watanabe:

As I understand from here you can use digest for web services while keeping default Liferay (basic) JAAS authentication for overall portal, am I right?

Yes, but the configuration for 6.1 is different, in fact it's the configuration that is mentioned in the first post

Kenji Watanabe:

Tomas Polesovsky:

Custom AuthVerifier should help.

You mean writing custom Authenticator implementing com.liferay.portal.security.auth.Authenticator?

No, I meant a class implementing AuthVerifier interface, but this is available only from 6.2

Kenji Watanabe:

Kenji Watanabe:

Is there no ws* security with xmlencryption implementation in Liferay available?

Tomas Polesovsky:

Not in <= 6.2. We use Axis1 to avoid conflicts with app servers WS-* libraries.
In 7.0 it should be possible.
.

That would be very useful but in the meantime I need a way to encrypt (at least partially) credentials for web service calls.
I understand you suggest to write custom verifier to enable full credential encryption?

In 6.1 you can also implement a new ServletFilter similar to SecureFilter and use in your plugin. All you need is to:
1, validate authentication credentials / tokens
2, initialize authorization context ... https://github.com/liferay/liferay-portal/blob/6.1.2-ga3/portal-impl/src/com/liferay/portal/servlet/filters/secure/SecureFilter.java#L187-L207

Best,

-- tom +

[Kenji Watanabe, geändert vor 8 Jahren.]

Thanks a lot Tomas,
I will have a look at custom ServletFilter.
Maybe another option is to use third party authentication service to obfuscate credentials.

Regard

Kenji