I am creating a Hotspot network, where I need users to first register in order to get credentials to connect to the internet.
My worry is how does the registration form gets sent to my database which is hosted on AWS putting into consideration that the client who is registering doesn't have Internet yet.
Anyone who has a suggestion on how the process works..?
Thanks
So basically you need to have a route(and a NAT rule) for all unauthorized clients to be able to talk to the endpoint storing/processing the form (i.e. Database).
This way every one can communicate with target and after
authentication they should be provided by a full internet accessible
route.
Related
I am building an ERP and I decided to deploy it on AWS. I already coded my frontend in REACT and my backend in python Django. They are both Dockerized and I will deploy them with on ECS Fargate and with PostgreSQL on ECR. All of this contained in a VPC.
I want to create 1 VPC per client/company with their own pool of users authenticated with either Django or cognito. I'm not sure yet.
But I am wondering if I can have a landing page with my domain name where clients would be signing in with a cognito pool, giving them access to their respective VPC in a subdomain. And then signing in as a user in that VPC on a different sub-pool. Won't I have a token conflict being on the same domain?
I think having those 2 layers of auth would avoid chances of having clients accessing the wrong database.
(example: new user created in the wrong pool)
This is my first post, although I use this forum a lot. I hope it is clear. Let me know if you need more details
thanks
Update: so it seems I'm trying to do a multi-tenant application. I made I diagram to show what I am going for. The setup for each individual VPC, I'm almost done and got a good idea how to implement it. It's the top part that can't wrap my head around.
enter image description here
I think there should be not "two layers of authentication".
You should authenticate users with Cognito only once and assign authenticated users an IAM role. This IAM role and policies linked to it are used to control user access to different AWS resources.
There are several ways to achieve this. Some of them are depending on AWS service quotas, overall application and service arhcitectures etc.
You may find this AWS document useful: https://docs.aws.amazon.com/cognito/latest/developerguide/multi-tenant-application-best-practices.html
If you are able to provide a conceptual architecture diagram with all the AWS resources you are intending to use, there will be a change that you receive more detailed answers.
I have a react web application with a flask api (I used to use express). The product of this app is the data that it displays. I don't want other people to be able to take that data easily from calling the api.
I want to secure the api such that it can only be accessed by my react app and nothing else. How can I do that?
The only way to truly secure your API is by authenticating your app's user with something like Oauth2 and verify that credential on server-side with something like passport, and make the authorization expire with sessions. AND use SSL so none of that is easily visible through a protocol analyzer.
Sure, you can hard-code some sort of "secret key" with the app, but anyone who want it bad enough will read it off your app or sniff the packets through a packet logger until they find the key.
EDIT: Oh, and as a part of the authorization upon login, provide them with a uniquely generated "API-KEY" as part of identity, so you can validate them upon submission, and if they violate your trust, mark their API key invalid in the server so they can't use them any more.
First, if your client code and API server are running on different domains or ports, configure CORS on your API server to only honor requests that originate from the client code's domain. Second, authenticate legitimate users so that only authorized requests for data are honored. There are lots of 3rd-party libraries to help with authentication.
One of our clients requested that we integrate our system with ADFS (Active Directory Federation Services) while another requested that we integrate with Okta. They want the experience to go something like this: the end users opens up the Windows app (on their domain joined computer) and is able to use it right away with implicit authentication from one of those identity providers. No extra clicking or registration. I am willing to create multiple copies of the application integrated into these different identity providers if necessary.
Our current setup uses Node/Express as a backend (hosted on amazon web services) and all traffic is sent through this API. Our client interface is a wpf Windows application. This seems to be a less common setup. Currently, the user must sign up with an email and password, and must log in using that same email and password to start using the application.
There are 3 parts to this question that I'm super confused about (I'm an intern with limited knowledge, so please explain like I'm 5 if possible). On the other hand, I believe I have a solid understanding of how Single Sign On conceptually works (with us being the service provider and ADFS/Okta being the identity provider). Even if you can answer parts of these questions, I would be super grateful!
What (if anything) do I have to do to our API backend? I'm assuming everything just needs to be done through the windows client right? But then I saw a passport saml package but I'm unsure if I need it to complete this task.
What do I have to do to our frontend? I've tried one of auth0's sample windows application but it seems like everything is still going through a login screen. At least for any social media connection. We'd like to ideally do this without a login screen and hopefully without proprietary software like Auth0 (since we manage our own user database already). We just want something so that at startup of our wpf application, the application queries for user's information (through ADFS or Okta) and then all behind the scenes, the user is logged in automatically. Any pointers here?
What I do have to do on the 'main' active directory Windows server side (this would be on a client's enterprise network)? I've seen hints of setting up callback urls, certificates, metadata, and something, but I'm unsure of what all of that is. Lots of questions just reference that but don't explain what or why it's needed?
Lastly, I apologize if any of the questions are vague, I have tried to do research, but it just seems like all the pieces are either too advanced or just don't apply to my setup. Thank you for your time!
ADFS etc. rely on federation protocols like WS-Fed and SAML 2.0 and so the IDP behavior is determined by the protocol.
There is no browser based functionality to just log you in.
You will always be taken to an IDP login screen. Once you have authenticated, other applications on the same IDP won't require authentication. They can seamlessly log you in based on cookies.
You can't query for user info. until you know who the user is.
On the ADFS side, you can manually configure a RP (your app).
I have been trying to determine a good strategy for authentication between a single WPF application of which calls to Web API services.
The client WPF app should be the only application to ever call the Web API.
I think I do have some unique requirements I must abide by. For example, The boss does not want to use ssl in any way; he is paranoid of users may having to deal with certificates.
Like I said, the client application is the only client using the Web API. The API just calls a list of stored procedures on a separate server.
Currently, we have a user membership database that does not align with any membership db standard, but we currently have over 200,000 members. One of the stored procedures currently authenticates the user with the membership db. The client application requires valid users to sign in to the application at start-up, however, we are wanting to secure all of the Web API requests sent from client to prevent non-valid requests being made to the server and so to prevent.
We are concerned about using the individual accounts or local authentication to essentially authenticate every web API request because of the added cost.
I have been thinking that what we are really needed to do is pretty much authenticate that it is our software client(WPF application) making the request and this authentication could open up all the controllers and actions for requests made by the client rather than the user. The user and its authentication is somewhat separate and is in place to prevent unauthorized users on a particular machines install of the application.
So you must have a valid user account to use the application.
Any suggestion would be great. I am just asking to get pointed in the right direction. I am really new to security so all suggestion will be valuable to me.
Thanks.
We have an intranet web based information portal. Now, under development is module for internal orders.
The problem is: When the approver approves the order, it accesses page that requires https and accessing it should be much secure than a simple (second) password authentication.
The first idea was to pair certified connection between the server and client, i.e. the server should recognize that client has installed appropriate certificate, otherwise, to show inaccessible page message.
We played with OpenSSL certificates, but because we are newbie in that, there was no success.
Which is the right way to do this?
Probably, this is important: The certificates was done under Linux. They should work on Win2003 server with installed Apache2 with enabled SSL module (PHP, MySQL). Also - pages can be accessed only via IP address of the server. Is it OK to configure certificate for IP address? Information we used to generate certificates is here.
Is there another way to secure connection between client and server in that case, i.e. to ensure that only privileged client (computer, browser) is accessing the secured page? If you have other suggestions, they will be well appriciated.