Handle Authentication and Authorization in jax-rs webservice with cxf - web-services

I have a webapp which has jsps. am not using any struts or mvc framework. We have JAX-RS service build using Apache CXF.
Now i want to do following
Allow user to login with username and password.
For all subsequent calls to webservice, same authentication info should be used.
Logged in user has some details (profile photo, full name), which i want to keep it constant across session.
Also, its role are defined. Based on role(s) only certain jax-rs calls will be allowed.
Roles are also used in JSP to restrict access to functionality.
Web services can be accessed outside so authentication and authorization info should be used.
As far as i understand, We should not use session in jax-rs services. What is the best way to handle above situation ?

The best way depends on how you estimate it.
My way of doing this is to
Run Rest service and JSP on the same instance
Use web.xml and CXF to set up security policy, which allows user/pw authentication and authorization, ROLES binded to both jax-rs urls and JSP urls.
Based on 2, jax-rs services can be called directly outside, but user/pw is required as you specified.
Hope this can help you a bit.

Think cxf security validation as any other http or https validation. you have to intercept the request and pass it to the rest service. You can use any of the tools like siteminder, else can write CXF interceptor to do your own security validation. In the interceptor you can call SSO kind of token generator server in case you have the infrastucture or call the DB if your architecture is built that way. You can use caching to reduce the resource hits and can look at custom or hibernate cache. enabling Https has to be done in server configuration. If you have certificate , you can use the same else you can generate your own using openssl.

Related

Does camunda have rest api for authentication

Is there rest api to use for login and logout in camunda rest api.
I want to create stand alone front end for camunda. The problem is how can i authnticate a user via rest api of camunda engin ???
From the Caunda User Guide:
https://docs.camunda.org/manual/latest/user-guide/security/
Deployment Options and Components
Embedded Java library inside an application: in this case, the Camunda engine is embedded inside a custom Java Application. Usually
the application takes care of securing access to Camunda’s APIs and
the APIs are not directly exposed to an end user. In this case, the
application typically takes care of ensuring authentication and
preventing access by unauthorized users.
Shared Process Engine: in this scenario, the Process Engine is deployed as a container service into an application server such that
it can be used by the applications deployed into the same container /
server. This case is similar to the embedded Java library case.
REST API: the REST API provides access to Camunda’s core APIs through HTTP. In this case users can directly access Camunda’s APIs.
Usually, it is necessary to configure authentication, authorization
and also secure the connection to the REST API using SSL (HTTPS).
Web applications (Cockpit, Tasklist, …): similar considerations to the REST API apply.
In other words:
Camunda is flexible with respect to authentication options
It's YOUR responsibility to choose the appropriate authentication mechanism for your particular use case, and configure Camunda accordingly.
SUGGESTION: Best practices for REST API security: Authentication and authorization

authentication/autorisation web service: Oauth or not?

We need to implement an authentication/autorisation web service and I am not sure if we should use the Oauth protocol in our situration.
The background of the story:
We have some J2EE web applications in a jboss server. Authentication and authorisation of the applications are implemented by JAAS and deployed in this jboss server.We want to add some new web applications that are implemented in other languages and deployed in other servers. To re-use the authentication/autorisation mechanism in the jboss server, we need to implement authenication/authorisation web services for the new applications.
So here comes some thoughts:
Is it necessary to adapt the OAuth protocol for the authentication/autorisation web service ?
As I know, OAuth2 is use to grant access to functionality, user's data, etc.. without giving the password to the 3rd party app. This is not really our case as we actually own all the applications, although that the newly apps are not in the authentication server.
Another choix is to implement the login webservice et then return the new apps a ticket/token to use later.
In another way, with OAuth protocol, newly apps do not involve in user's login/passwords, which seems to be nice...
Do you have some ideas ?
OAuth works on the concept of "ResourceOwners (Which gets the user credentials and enables the client's access to the server's apis)", "Server (owner of the resources) and the "clients (who want access to the server resources but doesn't have access to the credentials).
OAuth is just one way of providing security to the resources which means it is not necessary to have it for all "authentication/autorisation".
In your case I dont think there is a need of full fledged 3-legged OAuth however you can still go ahead with 0-legged OAuth or some other approach. Also, I don't understand what did you mean by "newly apps do not involve in user's login/passwords" as this is completely composite to what OAuth is meant for. User generally provide the credentials when they login into the app and then that login call ensures that the clients have access to the server resources.
If you just want to "return the new apps a ticket/token to use later" then OAuth is not for you as it is more than just providing the token for later use. Also, token in OAuth is for server's api access.

how do i secure a JAX-RS backend that uses Angular js client

I'm almost done with a jax-rs webservice so currently I'm now working on security part, I have read several articles on implementation of jaas and jdbc realm roles. some how no one seems to talk about authenticating a user from a remote angular js client.
Assuming i set my roles in jdbc/realm and configure my web.xml file ,can i do this?
<form-login-config>
<form-login-page>+"http://54.200.2.152:8080/service/index.html+"</form-login-page>
<form-error-page>+"http://54.200.2.152:8080/service/error.html+"</form-error-page>
</form-login-config>
to re-direct to the remote angular-js client? and if i do that,how to i maintain the js_securitycheck session id? (meanwhile; sessioning is against rest principles, which is stateless .
Also, is <auth-method>BASIC</auth-method> preferable for using a remote angular-js client? sending basic64 code and how do I implement this?

Authentication for Hospital Management system

I am implementing a Java EE based Hospital Management System that has a web service and two clients are to be connected to it, a Java Swing App and a JSP-based web project. The web service is to be implemented using Stateless EJBs.
Please suggest a way of implementing authentication and login for both clients (Users are taken from database-DB2)
NB: This has to be submitted as a project so server(Websphere) based authentication should be avoided as much as possible. Could not find any resource corresponding to this scenario..
I suppose that users will authenticate to both applications with username (and password). If you don't need user authorization on the service side, you can just create username/password combination for each client and store it in web service configuration file. In that case i would suggest message level security for clients.
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Ftwbs_securews.html
In case you need user authorization on service side, you can still rely upon message level security but proceed users credentials instead.
Here are also some examples which might be helpful:
http://www.mkyong.com/webservices/jax-ws/application-authentication-with-jax-ws/
http://www.ibm.com/developerworks/websphere/tutorials/0905_griffith/section7.html

Securing REST web service in GlassFish

everyone.
I have a problem securing my REST web service. It's part of Java EE web application. To secure the pages I used login-config tag and set up "FORM" authentication. Now I don't know how to secure web services, because "FORM" is not appropriate for it and I can't have two login-config tags for app. I considered splitting into 2 apps, but don't think it's a good idea. Any suggestions?
This has info on how to create secured web services using NetBeans: http://netbeans.org/kb/docs/websvc/wsit.html
Many web service providers use an api key to authenticate access to the service. You may want to consider doing something similar for your service.
It is pretty common for the REST API to have a separate subpath - that way you can specify the auth constraint just to the URL's specific to your application and for the URI's corresponding to your REST API implement authentication using jersey OAuth filter or something else.
In case your app is all written in Jersey and you would like to expose exactly the same URI's for REST clients as well as browser (and differentiate just based on the requested media type), you can have a "login" URL (for displaying a login page) and only that you could protect using FORM authentication. Then again you would add Jersey OAuth filter (or other auth filter) which would not kick in unless there is OAuth header in the request, and another filter where you would check if ContainerRequest.getUserPrincipal() is null. If it is null, you could return Response.seeOther(UriBuilder.fromPath("/login").queryParam("redirect", request.getAbsolutePath()).build()).build() - that will redirect to the login (for oauth this would not kick in, since either the oauth request would succeed, or the previous filter would fail and return Unauthorized or Bad Request status codes). In the login resource you can use the redirect query parameter to redirect back to the original page once successfully logged in.