I have very simple question: What will happen when I have SESSION scoped bean in my application which is STATELESS?
Long story. I have backend application, written in Spring Boot, which serves REST API for frontend written in AngularJS. I'm using JWT for authentication proccess and the Spring Security is configured to be STATELESS.
But I'm also using WebServiceTemplate to communicate with SharePoint. My beans responsible for communication with SOAP API are SESSION scoped beans because they depends on user credentials. It's very hard to configure WebServiceTemplate to use different credentials for every call so I decided to configure on creation and then my problems started.
As soon as you are storing some state into session scoped bean, your application becomes stateful.
If you need to share state (in this case SOAP service credentials) between requests and want to have stateless application (e.g. because of clustering of your app), you have few options:
Store that state into DB and optionally cache it in service. (If SOAP call fails, you can invalidate cache and read fresh credentials from DB)
Use Spring Session project or some key-value store to store session state.
Related
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
I'm struggeling with an stateless Flask Application. Normally I use flask-login to handle all the user management. But now I need to do this stateless cause the application should run on cloud run. So it has to be stateless.
My included RestAPI works perfectly (I use tokens there). But how could I handle the stateless part on the frontend?
How could I get the Userinformation in the request? At a stateless server I can't use the clientsession cause I could not verify it in a request? Also I could not use my lovely current_user variable :(
Any help?
Pascal
There are several types of authentication and Flask-Login uses one called session authentication if you want to make your app stateless you should use token authentication like OAuth2 or JWT. Have a look at Flask-JWT, Flask-JWT-Extended and Flask-OAuthLib.
But this doesn't mean that you have to refactor your application you can just enable the sticky session feature from your cloud provider load balancer.
Have a look at the following documentation for doing that on AWS: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html
I need to build some web services in a WebLogic application server. This server lies between a mobile app and Oracle ERP. Basically, after the mobile app "login" to the Oracle ERP via a web service call on the application server, a session should be maintained on the application server. One reason is this:
Every time a web service is called by the mobile app, it needs to return a random challenge token. This is a requirement by our internal security. Within the same session, when the same mobile app calls the same web service (or a different web service) on the application server, it needs to pass the challenge token that it received previously. The application server will then have to check that the token is the same one that it returned previously to the mobile client.
We have discussed about using JAX-RS for communication between mobile app and the web services. However, I have read that JAX-RS is supposed to be stateless. In this case, how can I maintain a session such that the application knows the challenge token that it returned to a client previously? There is no database for the application by the way. Normally for a web application, it can just save the challenge token to a session object, but how do you do so for a web service?
If JAX-RS cannot maintain session, then what about JAX-WS?
Thanks.
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.
I am making heavy use of async requests by Javascript to the webserver. Since I am building a multitenant application, I want to restrict access to the json services on the user level.
I read a lot about OAuth being recommended for consumer authentification. In my scenario, would the Javascript (client) side be regarded as the consumer and, hence, would you recommend using OAuth for that purpose? If not, what alternatives would you recommend?
OAuth is best at providing a method other than direct sharing of username and password with third party applications or web sites. I would use OAuth or something like it only in the case that you need to provide this type of third-party access to your web application.
If the JS client will be running in a web browser that the user has already logged in to your service, you might just as well use the session cookie that you have already established to authenticate each request.
In fact, such a session cookie will automatically be shared as part of any XHR to your web service.