I have a high-level/conceptual question about Shibboleth.
I'm working on the front-end (running Drupal) of a data-driven web app. End-users interact with the front-end to construct data queries, which makes background requests to a caching/archiving data proxy (the "data retrieval service"), which in turn either delivers data from its cache or goes out and queries still more services ("out there") which have desired data. So far so good... it is ornate, but only as ornate as the problem we're trying to solve.
Here's the wrinkle: Some of services queried by the data retrieval service want to implement user-level authentication, so that some users may access their data, but others cannot. For organizational reasons, our identity and authentication mechanism is likely to be Shibboleth.
So, here's my scenario: a user logs in to the frontend using Shibboleth. Now, can my frontend, and in turn, the data retrieval service, authenticate against against external services as the user? And if so, how does that work in practice (what authentication data gets passed from server to server)?
Yes it can - you service has to exist in the identity provider (how it is set up is up to you)
Related
I’m currently working on a PoC with multiple Quarkus services and Keycloak RBAC. Works like a charm, easily to bootstrap and start implementing features.
But I encountered an issue that I could not solve in my mind. Imagine:
User accesses a protected service
quarkus-oidc extension does fancy token obtaining by HTTP redirecting, JWT in cookie lasts 30 minutes
User is authenticated and gets returned to the web application
User works in application, fills in forms and data
Data is being stored by JWT-enriched REST calls (we do validation by hibernate-validator)
User works again, taking longer than 30 min
Wants to store another entry, but token from step 3 is now expired and API call fails
User won’t be happy, so me neither
Possible ways to solve:
Make the JWT last longer than the current 30 minutes, but that just postpones the issue and opens some security doors
Storing users’ input in local storage to restore it later after a token refresh (we also would do that to not loose users’ work)
Refresh the token „silently“ in JS without user knowing. Is there a best practice for that?
I missed something important and the internet now tells me a better architecture for my application.
Thank you internet!
Re the step 3. In Quarkus 1.5.0 adding quarkus.oidc.token.refresh-expired=true will get the ID token refreshed and the user session extended if the refresh grant has succeeded
For such use cases, I tend to prefer the reverse of JWT. I keep the user data in a shared data service (a data grid like Infinispan or Redis). So that this data is keyed by the user and available. I do control the TTL of that data in the shared data service.
It can either be specific to an app, or shared between a small number of apps. It does bring some coupling but so does the JWT property structure.
For Quarkus, there is an Infinispan client integration, a Hazelcast one, mongodb and AWS dynamoDB. And you can bring other libraries.
I am developing a web application with Spring Boot and a React.js SPA, but my question is not specific to those libraries/frameworks, as i assume reporting client-side JS errors to the server (for logging and analyzing) must be a common operation for many modern web applications.
So, suppose we have a JS client application that catches an error and a REST endpoint /errors that takes a JSON object holding the relevant information about what happened. The client app sends the data to the server, it gets stored in a database (or whatever) and everyone's happy, right?
Now I am not, really. Because now I have an open (as in allowing unauthenticated create/write operations) API endpoint everyone with just a little knowledge could easily spam.
I might validate the structure of JSON data the endpoint accepts, but that doesn't really solve the problem.
In questions like "Open REST API attached to a database- what stops a bad actor spamming my db?" or "Secure Rest-Service before user authentification", there are suggestions such as:
access quotas (but I don't want to save IPs or anything to identify clients)
Captchas (useless for error reporting, obviously)
e-mail verification (same, just imagine that)
So my questions are:
Is there an elegant, commonly used strategy to secure such an endpoint?
Would a lightweight solution like validating the structure of the data be enough in practice?
Is all this even necessary? After all I won't advertise my error handling API endpoint with a banner in the app...
I’ve seen it done three different ways…
Assuming you are using OAuth 2 to secure your API. Stand up two
error endpoints.
For a logged in user, if an errors occurs you would
hit the /error endpoint, and would authenticate using the existing
user auth token.
For a visitor, you can expose a /clientError (or
named in a way that makes sense to you) endpoint that takes the
client_credentials token for the client app.
Secure the /error endpoint using an api key that would be scope for
access to the error endpoint only.
This key would be specific to the
client and would be pass in the header.
Use a 3rd party tool such as Raygun.io, or any APM tool, such as New Relic.
I'm getting into the world of fullstack development and I'm trying to develop app which front is completely separated from backend (front is being served from node server and backend is java).
Now, the issue - how should I get about securing my app?
I'd like to have many fronts and many backend instances connected through load balancers and I'd like to keep all the state on client, so I can without any issue switch to another backend server and continue as nothing happened.
Currently I'm using OAuth2 tokens but I'm concerned about security and stealing the tokens, which are completely stored in cookie on user side. Also, The app (obviously) stores those tokens somewhere, so another instance of my backend app wouldn't accept the token. In best case scenario I can implement some mechanism that would automatically request a new one and in worst case I'd have to login again. I don't want that to happen.
Also, here I have a problem with social auth. Allright, I'm receiving token from Google on front, but giving it to backend and creating a user there is major pain, I have to write a lot of code manually to create such user and save it.
And again, I'm not certain about security level of this solution.
So the question is basically - currently, what is the best way to secure an app which should have completely separate front and backend, which would have no issue with switch backend server between requests?
As regards tokens being stolen from the Client: you can't do anything about this. It is up to the client to protect themselves. What I mean is, if you need a username and password to access a service, and the Client is infected with a key-logger, and a hacker steals those credentials, there is nothing you can do on the server side to protect against this.
As regards your idea of multiple back-ends, this is a common feature of any system with multiple application servers. For example, if you have multiple web servers and want any request to be routable to any server. For this, you need a central database which stores any information which needs to be shared. It's slower, obviously, but much more resilient.
I am coding a webapp (E-commerce) for learning purpose using AngularJS + BootStrap and REST.
I have used Apache Wink for REST WS and and application is deployed on JBoss EAP 6.4. My application is working fine.
I can access the back end data using AJAX and webpages are getting populated properly. The issue is security of REST WAS. If I use REST URL directly on browser, without going through front end, JSON data gets populated and my data is exposed. What design changes should i do ?
Please note that initial operation on the website for e.g. browsing the products, adding them to cart etc are stateless. No user's identity is needed for these operations. I still need to secure my data for these interactions. Please suggest, how can I do it.
Sunil
If you want to lock down the services, you may require some type of authentication (for example user/pass) that returns a security token (over https). Then all subsequent function calls may require the security token to be passed in as a parameter (if the operation is sensitive). The token will require a session timeout.
However, if the data is also publically shown on the site, then there's not really a security risk in itself. IOW, how is this any different than them using the public website to get/update data? The rest services usually shouldn't require any additional level of security beyond what is already used on the website to protect the data.
I am working on a webapi project which of course is supposed to be stateless.
The point is that it requires authetication and the majority of it's services is available to logged in users.
The catch is that there are several pieces of information about that user which should be used on all subqsequent calls to the legacy backend.
Should I force the clients to send back all those parameters on each request? (doesn't seem fair)
Should I use a caching on the webapi side - this is tricky as currently there is no out-of-memory distributed cache in use in the deployment environment....
What options do you see?
You could choose to issue the user some kind of session token on the first call. The server could then use the session token to authenticate the user and remember the settings for that session on subsequent calls.
You can read more about managing sessions in a stateless environment here:
http://en.wikipedia.org/wiki/Session_management