I'm working on developing my first SOA web-based application. I'm extremely new to SOA and still trying to wrap my head around best design principles for service design, especially in the way that services should talk to another.
The current problem I'm trying to figure out has to do with authentication and authorization. Lets say I have a trivial user service and event service, where the event service represents events in a calendar. Is it general practice to have the event service call the user service to authorize the request? Or, would it be better practice to implement user authorization on a system that exists between the client and the requested service? The system, which is essentially just another service, checks to user credentials to make sure they have access to the requested action (GET events/1, etc) and if so, sends the request to the service. This service could also act as a central load balancer and cache...I just like the idea of keeping user logic outside of each specific service.
You can use siteminder as authentication and authorization. Only the client who has valid token can invoke the service. you could also have roles assigned in siteminder.
Related
I have been doing some research about using some AWS service as OAUTH2 for our application running in 3 docker containers (backend, frontend, database). Backend has an API which is not open to public obviously and accessible only within docker network. We are looking for extending our app with a chat service, which we want to implement as a service, so we build our app following microservices architecture, since we will add other services later on. So when user logs into our app, his session will be also "shared" with chat service.
Our chat service will be using sockets and since sockets require direct connection to user resources, we can not just implement an integration layer which will supply all resources required by chat service, but we have to either:
implement sockets within our application API (which we dont want to do, we want it as microservice),
open API endpoints for chat service to use, but this option requires OAUTH2 and thats what we try to deal with.
I am not sure if there is some other way to handle this and be also ready for a long run, but if this works, which AWS service would fit the best for us to use, which would play OAUTH2 role for handling security in this matter?
I also checked this post but it didn't help me much in my case. I'm open to any suggestions, I've checked AWS lambda, AWS cognito, AWS amplify, pretty confusing, many features, we don't want to overload the architecture with features we don't need.
What exactly is the thing you want? User accounts managed by AWS? Use cognito.
Users logging in with Apple, Facebook, Etc? Use cognito again.
Just have some backend code that once a user logs in, create a token or session so they can chat with that.
There are many youtube videos on AWS cognito but a lot of them suck. The best one is written in React but before they came out with hooks. Here is part one. https://www.youtube.com/watch?v=EaDMG4amEfk
I am working on a NodeJS application which exposes some APIs. This APIs can be accessed by different vendors (Without any browser). Now I want to know what is the best way to Authentic/Authorize these vendors using AWS Cognito service?
Should I give a client ID (Username) and API_KEY (Password) to my vendors and Validate it through cognito for every subsequent requests. (As of now it is already implemented from the Database)
[OR]
Should I generate a access and Id token for the vendor with MAX validity and give it to the vendor. (I understand this isn't the best practice)
So what should be the best way to achieve this?
Define app clients in your user pool, one for each of the "foreign" servers. When you create them Cognito will generate an app client id and a secret (if you check that box...and you should check it). In "App client settings" (AWS Console for Cognito) you tell it the client will use "Client credentials." Finally, define whatever custom scopes you think you can leverage to provide finer control of access. These can be different for each client.
Now the foreign server can authenticate/get-authorization by passing in the app client id and the secret, etc., etc. Usual Cognito stuff.
I am designing a "simple" RESTful API and in dilemma between the tow following designs:
Top design:
user send request to api getway which authenticate with cognito
api getway redirect to ALB that redirect to the ecs.
in case of a "CACHE" end point, the user would be redirect to lambda that would extract and return the data
bottom design
user request is authenticated by the ALB and move forward to the app, the app extract from cache.
My questions:
is the API gateway and lambda necessary? should I except a greater latency in the bottom?
An advantage I see at the top design is that i am able to distinguish between sync and async request, is it a good practice?
i learn recently that ALB can make the authentication to cognito , can it also make authorisation to an endpoint?(check if a user belongs to a group that allow to access this endpoint)
More general, I am trying to get the best design to avoid latency, I have an endpoint that doesnot need to get live data and can relay on cashe.
thx in advance!
I have a client side application (developed in Java, not Android) that authenticate a user with an Amazon Cognito User Pool. To make things clear: that application display a username/password entry dialog, then authenticate with the Cognito user pool service using the SRP method; potential challenges are handled in that dialog (device id, password must be changed, two factors, etc). In the end, I have a series of tokens that allow the program to use AWS services with the user's credentials.
Now, I need the client application to communicate with a custom server side application. The client will have to prove its identity to the server application, which will then communicate with more AWS services. Here, I have two distinct use case:
1) The server only needs to know who the client-authenticated user is (in a safe manners, but without impersonating the user).
2) The client needs to delegate some or all of privileges of the user to the server; the server will then perform some actions on AWS services under that users behalf.
The server side application will most likely be developed in Java, running on an EC2 machine. I'm only interested in user authentification through the Cognito user pool source (that is, I have no interest in Facebook/Google/OpenID-based authentication flows).
It seems rather easy to achieve both objectives in very unsafe manners: just have the client application send to the server all the tokens it has been granted. But this is obviously not the way to go.
Yet, I'm having a hard time figuring out from Cognito User Pool/Cognito Identity Pool/IAM/STS documentation how this can be correctly achieved. I would expect for example the possibility for the client application to be able to generate some kind of "delegation token", which can be passed to the server; the server should then be able to validate that token and extract identity information from it (satisfying #1), or to impersonate the identity corresponding to the token in order to perform calls to AWS services (satisfying #2). Or maybe I'm thinking this incorrectly?
What you are pointing at is OAuth 2.0 code grant flow which is not currently supported by Amazon Cognito.
The current available safe way to do this is to pass the id token from the client to the server and then validate that token and extract identity information from it. This proves the identity of the caller as you can validate the signature of the id token.
So I may be barking up the wrong tree here, but I have got the api manager working against rest services and can provision users through LDAP.
I can restrict access to certain services by role.
All good so far, however as many users will authenticate through a SPA (AngularJS) and the application will call multiple Rest Services, what I don't want users to have to do, is go to the store and subscribe to all relevant APIs, I would like the users from the LDAP server to be subscribed to all relevant services and have the roles they have limit access to the service.
Is there a way to have authentication done by just being in the identity store and authorization to be managed by the restrict by role setting.
Does this need scripting, is it a setting, or is it impossible?
Thanks in advance
Your requirement isn't supported OOTB in API Manager, still you can do it with little effort.
API Manager provides REST API to subscribe APIs. You can write a client which call the REST API onbehalf of the user and subscribe him.
Have a look on REST API