Remote JSON web service access and CAS authentication

[Dicta Artisan，修改在6 年前。]

I have a question and possibly a bug relating to JSON Web Service access authentication

Here is the bug scenario:

• fresh installation of liferay-ce-portal-wildfly-7.0-ga4-20170613175008905.zip
• set up a portal-ext.properties including:
  
  • fresh mysql database connection
  • default admin user as 'admin' with password 'foo'
  • auth type screenName
• start the server and configure CAS authentication
• in the CAS authenticator configure credentials for authenticating user 'admin' and password 'baz'
• restart everything

Now I can

• Log into the portal via CAS using credentials admin:baz
• Invoke remote JSON web services using basic authentication using original credentials admin:foo e.g. using
  

  curl -u admin:foo https://myliferay/api/jsonws/user/get-current-user

The bug seems to be that remote Json web services allow authenticating with a different policy than what is configured in the portal.

The underlying question is, how would you see remote JSON web service invocation from an external application when CAS authentication is configured in the portal. I've been reading around about the various options available - would it require obtaining a p_auth token, and if so, how?

[David H Nebinger，修改在6 年前。]

Dicta Artisan:

The bug seems to be that remote Json web services allow authenticating with a different policy than what is configured in the portal.

The underlying question is, how would you see remote JSON web service invocation from an external application when CAS authentication is configured in the portal. I've been reading around about the various options available - would it require obtaining a p_auth token, and if so, how?

It is not a bug, it is how it is designed.

The APIs are (typically) not meant to be used in a headless way although you can by using the basic (digest) auth verifier.

The /api/jsonws path is protected by the basic auth verifier and the session auth verifier (that's the p_auth guy). If you wanted to allow other auth verifiers, you just have to update the configuration of the verifiers to indicate the additional path(s) to verify.

p_auth token is returned during login, so to get one you'd have to mimic the login form submit and process the response to get the p_auth value and then submit requests passing in the p_auth token. Since this is based upon the http session, the p_auth token may only be valid for the duration of the http session (I don't know if /api/jsonws calls actually trigger the session extension or not).





Come meet me at Devcon 2017 or 2017 LSNA!

[Dicta Artisan，修改在6 年前。]

Thanks for the quick reply

David H Nebinger:

p_auth token is returned during login, so to get one you'd have to mimic the login form submit and process the response to get the p_auth value and then submit requests passing in the p_auth token. Since this is based upon the http session, the p_auth token may only be valid for the duration of the http session (I don't know if /api/jsonws calls actually trigger the session extension or not).

I think I understand - In fact I can confirm I can successfully call the JSON api service via curl as long as I pass the JSESSIONID cookie along with the p_auth token "borrowed" from the web browser without having to use the basic authentication. I had some trouble replicating this earlier. So yes, the route to replicate browser login with CAS seems feasible (and keep the session alive if needed via a separate thread). Or I could look into implementing and configuring a custom CAS based verifier...

Nevertheless I still feel the original issue is a bug:

In my scenario I would automatically import users from LDAP after CAS authentication - and these users won't have a password in Liferay as I don't have access to their password (nor want to). Under the standard configuration these users would get API access without a password then? It might also become a hole for administrators that first set up the site with a trivial password and then reconfigure and feel safe, without knowing that the basic auth verifier might allow access on their original trivial password.

Should I log a JIRA about this?

[David H Nebinger，修改在6 年前。]

Dicta Artisan:

In my scenario I would automatically import users from LDAP after CAS authentication - and these users won't have a password in Liferay as I don't have access to their password (nor want to). Under the standard configuration these users would get API access without a password then? It might also become a hole for administrators that first set up the site with a trivial password and then reconfigure and feel safe, without knowing that the basic auth verifier might allow access on their original trivial password.

Should I log a JIRA about this?

I don't think it is solvable actually.

With CAS, when you try to hit a protected resource Liferay will redirect you out to CAS for authentication. After successful auth via CAS, it redirects back to Liferay with an auth token (typically embedded in a cookie or a request header) and the Liferay side will use the token and verify with CAS that it is still good.

None of these steps are going to be possible, as you've seen, with a simple curl request, and that's really the test - if you can't imagine how curl would handle something like this (redirect to a web form to complete auth, complete auth and redirect back to original request w/ the auth token), then it won't be something any other COTS tool would be able to do.








Come meet me at Devcon 2017 or 2017 LSNA!

[Dicta Artisan，修改在6 年前。]

Hi David and thanks again for the reply

David H Nebinger:

I don't think it is solvable actually.
....
None of these steps are going to be possible, as you've seen, with a simple curl request

I don't mind making more than one web call from my external application (curl is just a quick test tool) - at least for myself the API usage scenarios would involve scripting a stateful client so keeping a server-granted authentication token between calls is not an issue. Now, with CAS, whether the client is aware of it and performs the authentication procedure, or whether Liferay itself could proxy the authentication (with some additional configuration of course) and provide a token to the client, either of these are technically doable. Of course this means some extensions and depends on your design goals...

In any case, the bug I am talking about boils down to the fact that the basic auth validator is enabled by default in the configuration. It's purely a default configuration issue. It sounds convenient to have it enabled - but when an admin changes from the internal user database to an external authenticator they effectively leave a door open to API calls using credentials that they no longer have under the radar. The assumption that the password tested by the basic auth validator and the password actually in use are the same is wrong. This leaves a security hole in the API

I could be wrong of course but I'd be happy if that was the case

[David H Nebinger，修改在6 年前。]

Dicta Artisan:

I could be wrong of course but I'd be happy if that was the case

The default liferay bundle and configuration are, well, ideal for demo and proof of concept configurations, but as I always tell clients, it is definitely not ready to be exposed on the internet OOTB, at least from a security perspective.

Every default works for folks that want to spin the tires and turn the knobs and get a feel for how she handles the turns. I mean, can you imagine how bad the initial experience would be if you downloaded the "hardened" Liferay and had to undo a lot of stuff just to see how it works?

That said, I believe there are "hardening" guides out there that discuss ways to secure the environment; if the default access to jsonws authentication isn't in there, it probably should be.






Come meet me at Devcon 2017 or 2017 LSNA!