I have several Web PI endpoints currently secured with an access key. I'm not opposed to abandoning this security model.
Now, we're building a web app that will consume the services. The front end will have a login screen to secure portions of the application. I also want to make the Web API services available for use by applications other than our own (think public API).
How should I secure my services and allow access from our own web UI and as a service?
There are many ways to secure Web API 2.0 endpoints.
It seems like you already secured your endpoint with an access key, no idea how your clients know the access key.
For your web app I would ask:
How is the user logging in as you described? What authority are they providing their credentials to? Can you use that authority to attach a token to the requests of your web service?
You mention you also want to provide a public access through a public api. What credentials will they have? What authority will they request access from? You could set this up many ways with different types of credentials e.g. user name and password/client certificate/access key.
Microsoft has some really good resources about this including:
http://channel9.msdn.com/Shows/Web+Camps+TV/Securing-ASPNET-Web-APIs
http://www.asp.net/web-api/overview/security
I can think of:
HTTP Basic Authentication
OAuth/OpenID Connect
Client and Server Certificates
Related
In my project, there is a mobile app, an angular web app, 4 micro services and one api gateway. The users with role 'agent' can enroll customers using the mobile app. The web app is for users with role 'manager' to see the customer data and finalize on the customer enrollment.
Here, if I want to set up Keycloak for authentication, should I add
every micro service as a separate client ?
Should I add mobile app and web app as separate clients in keycloak ?
CLIENTS
The web and mobile app must be registered as separate OAuth clients. They will have a client ID but no client secret since they are public clients. They will use PKCE and have different redirect URIs, eg:
Web: https://www.example.com/callback
Mobile: com.example.app:/callback
APIs
By default APIs do not need to be registered as clients. In most setups related microservices can just forward JWT access tokens to each other, as explained in the scopes article. This is a secure way to maintain the user identity.
APIs sometimes act as clients though, eg if they need to do something like create users in Keycloak programmatically. Identity systems provide User Management Endpoints to enable this.
So one of your APIs, eg a Users Microservice, may need to be registered as a client. It would use the client credentials flow to get an access token with a SCIM related scope.
GATEWAY
It is common, and recommended, for a gateway to act as an introspection client. This enables data in access tokens returned to internet clients to be kept confidential. Read more about this in the phantom token pattern.
I have a request to restrict the access (access control) to a small user community in GCP.
Let me explain the question.
This is the current set up:
A valid GCP Organization: MyOrganization.com (under which the GCP project is deployed / provisioned)
Cloud DNS (To configure domain names, A & TXT records, zones and subdomains to build the URL for the application).
Oauth client set up (tokens, authorized redirects URIs, etc.).
HTTPS load balancer (GKE -managed k8s service- with ingress service), SSL certificate and keys issued by a trusted CA.
The application was built using python + Django framework.
I have already deployed the application (GCP resources) and it is working smooth.
The thing is that, since we are working in GCP, all IAM users who has a valid userID#MyOrgnization.com can access the application (https://URL-for-my-Appl.com).
Now, I have a new request, which consists in restricting access (access control) to the application only for a small user community within that GCP organization.
For example, I need to ensure that only specific IAM users can access the application (https://URL-for-my-Appl.com), such as:
user1#MyOrganization.com
user2#MyOrganization.com
user3#MyOrganization.com
user4#MyOrganization.com
How could I do that, taking into account the info I sent earlier ?
thanks!
You can use Cloud IAP (Identity Aware Proxy) in order to do that.
Identity-Aware Proxy (IAP) lets you manage access to applications
running in App Engine standard environment, App Engine flexible
environment, Compute Engine, and GKE. IAP establishes a central
authorization layer for applications accessed by HTTPS, so you can
adopt an application-level access control model instead of using
network-level firewalls. When you turn on IAP, you must also use
signed headers or the App Engine standard environment Users API to
secure your app.
Note: you can configure it on your load balancer.
It's not clear in your question if your application uses google auth (but considering that you talk about org-restricted login I think so) - if that's the case you should be able to enable it without virtually touching anything in your application if you are using the Users API.
The best and easiest solution is to deploy IAP (Identity Aware Proxy) on your HTTPS Loadbalancer
Then, grant only the user that you want (or create a gsuite user group and grant it, it's often easier to manage)
We're getting ready to rewrite an old native windows mobile application that accesses data through a VPN. We'd like the new version (.NET Windows 10 mobile application) to access data through web services that are protected by Okta. What is the best way to do this?
Thanks!
The best way to do this depends on how the web services are protected.
The main thing to keep in mind is that you don't want to store any secrets on the mobile application.
In an ideal world, these web services would be secured with something like OpenID Connect (OIDC), allowing you to authenticate against Okta (the "IDP") to get access to the web services (the "Relying Parties").
However, the real world is messy, where some web services are protected via SAML, OIDC, OAuth, custom headers, etc.
Without knowing more about your setup, my recommendation would be to build against OIDC, using a proxy server (or "API Gateway") as needed to secure your web services using OIDC.
One of my co-workers at Okta has written a sample iOS application in Xamarin that implements OIDC, I suggest taking a look at the ViewController.cs file in that repository.
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.