I'm designing a REST service in Node, and I have a plan for authentication and authorization -- but I'm not certain whether there's an unforeseen flaw in the design.
I have a central API server exposed to the Internet. The server also hosts a manager application (which communicates via AJAX), but is authenticated separately from the API, per requirement.
My initial thoughts are to have the server authenticate the user with a login form, then send the user a token (all over HTTPS, of course) that can be sent with each request to the API server for authentication and authorization.
Are there any flaws with this methodology?
Related
I'm designing a Web API that will be consumed by external web server.
Only the external web server must be authorized to access the internal API.
The end user will be authenticated against external web server, but the username must be forwarded to Internal API when requesting data, because there is some data filtering based on the username.
What authentication mechanism should in the internal web api server?
I started with X-API-Key header, but then how should I provide username? I would like to avoid passing username in querystrings
I was thinking about basic authentication, where password would be the X-API-Key
bearer token could theoretically work as well, but bearer tokens are usually generated by authorization server, which is not an option in this case.
EDIT:
Note, that the end user does not make any API calls. It simply access a website build using some CMS and the CMS internally fetches the data and generates HTML response.
I'm starting out with Kafka.
I see that I'm able to pass headers when producing messages.
Traditionally one would have a web client (single page app) where to user logs in via some remote oidc idp and receives a token. That token is then sent via Authentication: Bearer token-here header to some RESTful backend where the token is checked for validity and the payload is processed, saved to database or other and something is returned or not.
Now there's Apache Kafka. It has a REST proxy. I can pass headers to the REST proxy and produce messages, or consume them, but I'm interested in the "secure my RESTful JSON API" part.
Currently, without Kafka, I have either a oidc proxy (using keycloak, that's keycloak-gatekeeper) that does the filtering of which request makes it to the backend, or I have a oidc client that does token validation as some middleware function inside the backend. In any case invalid requests doesn't get "logged" as they would in Kafka, I assume.
Where does oidc token validation and request filtering fit in the Kafka/Confluent ecosystem?
Assume we have a SPA that talks to the Confluent REST Proxy. Some logged in user wants to post messages and some non-logged in user should not be able to.
How does Kafka and/or its tools deal with that scenario?
Kafka commonly uses SASL and other Authorization plugins to prevent access.
Certificates would be distributed amongst clients (here, that is the REST Proxy). You would need other proxies or plugins around that to prevent further access or audit the requests, as with any other web server.
HTTPS certificates would be used to secure traffic to the REST proxy, but seems you're asking about something more specific.
There is no reference to OpenID in the documentation, only LDAP RBAC, as a commercial offering
Given that I would create an OAUTH2 authentication server.
Given that I would to have separate resource servers, exposing REST APIs.
What are the best communication practies between the authentication server and the API servers?
To explain OAUTH2 server would be a proxy authenticating the user and forwarding requests to different API servers, that are not third party, but under the hood of the OAUTH2 proxy, relying on it to know the agent (user) requesting for the given command\query.
The simplest would be that the authentication server will forward the user id (that is stored with ACL rules also on each API server) under a secure connection, and that access would be restricted to request forwarded from authetication server to resource API servers.
The auth server would in this case forward the user id, but this seems suceptible to mand in the middle attack (altought firewall on API servers would be configured to accept requests only from the authentication server).
Another problem would be compromission of the OAUTH proxy, giving automaticly grant to any request coming from it.
Are there ready solution and patterns to deal with this scenario?
Thanks!
Check the User Account and Authentication Service (UAA) from CloudFoundry. Maybe will help you. It is also available as a stand-alone OAuth2 server.
API Documentation, GitHub
I saw the word "endpoint" many times in OAuth documents.. However, I still don't know what does this word really mean.. Does anyone have ideas about this?
The OAuth 2.0 Authorization Framework
The authorization process utilizes two authorization server endpoints
(HTTP resources):
Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
Token endpoint - used by the client to exchange an
authorization
grant for an access token, typically with client authentication.
Its basically the HTTP web address of the authentication server. It could probably be server addresses depending upon how its worked. The first is for requesting access of the user the second could be for granting access to the application. this probably depends upon how the Authentication server is set up.
OAuth endpoints are the URLs you use to make OAuth authentication requests to Server. You need to use the correct OAuth endpoint when issuing authentication requests in your application. The primary OAuth endpoints depend upon the system you are trying to access.
Example Google has two end points:
Request access of user:
https://accounts.google.com/o/oauth2
Exchange tokens
https://accounts.google.com/o/oauth2/token
We are designing security for a green field project with a UI web module (Spring MVC) - the client, and a RESTful services web module (CXF) - the server, to be deployed as separate war files in the same Websphere app server. The system should be secured with Spring Security, authenticating against LDAP and authorizing against a database. We have been looking for the best solution to share the security context between the 2 apps, so a user can authenticate in the web UI and invoke its AJAX calls to the secured RESTful services. Options found:
OAuth: seems overkill for our requirements, introduces a fairly complex authentication process, and reportedly some enterprise integration issues
CAS: would amount to setting up an enterprise SSO solution, something beyond the scope of our engagement
Container-based (Websphere) security, although not recommended by Spring Security, and we're not clear if this could provide a solution to our specific needs
We're looking for a simpler solution. How can we propagate the Security Context between the 2 apps? Should we implement authentication in the UI web app, then persist sessions in the DB, for the RESTful services to lookup? Can CXF provide a solution? We read many threads about generating a 'security token' that can be passed around, but how can this be done exactly with Spring Security, and is it safe enough?
Looking forward to any thoughts or advice.
You want to be able to perform the REST web services on the server on behalf the user authenticated in UI web module.
The requirements you described called SingleSignOn.
The simplest way to do it is passing the HTTP header with the user name during REST WS calls.
(I hope your REST client allows to do it).
To do it in secure way use one of the following:
Encrypt the user name in REST client and decrypt it in REST server
Ensure that the header is sent from the local host (since your application deployed on the same container)
Therefore, protect both application using SpringSecurity authenticate against LDAP.
In the first application (Rest Client) use regular Form Authentication
In the second application (Rest Server) add the your own PreAuthenticatedProcessingFilter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6167
Edited
The “Authentication” is the process of verifying of a principal’s identity.
In our case both REST Client (Spring MVC application) and REST server (CXF application) verify an identity against LDAP. LDAP “says” OK or Not. LDAP is a user repository. It stateless and does not remember the previous states. It should be kept in applications.
According to my understanding, a user will not access directly to REST server – the user always access REST Client. Therefore, when the user access REST Client he/ she provides a user name and a password and REST Client authenticate against LDAP. So, if REST Client access REST server the user is authenticated and REST Client knows his name.
So, if request come to REST server with a user header name - REST server for sure knows that the user was authenticated and it should not authenticate it again against LDAP.
(The header should be passed in the secured way as described above).
Rest Server should take the user name, to access to LDAP and to collect related user information without providing of the user password (since the user already authenticated).