User authentication with Identity-Aware Proxy
1. Introduction
Authenticating users of your web app is often necessary, and usually requires special programming in your app. For Google Cloud Platform apps you can hand those responsibilities off to the Identity-Aware Proxy service. If you only need to restrict access to selected users there are no changes necessary to the application. Should the application need to know the user's identity (such as for keeping user preferences server-side) Identity-Aware Proxy can provide that with minimal application code.
What is Identity-Aware Proxy?
Identity-Aware Proxy (IAP) is a Google Cloud Platform service that intercepts web requests sent to your application, authenticates the user making the request using the Google Identity Service, and only lets the requests through if they come from a user you authorize. In addition, it can modify the request headers to include information about the authenticated user.
This codelab will walk you through creating your own application, restricting access to it, and getting user identity from IAP.
What you will build
What you'll learn
How to write and deploy a simple App Engine app using Python 3.7
How to enable and disable IAP to restrict access to your app
How to get user identity information from IAP into your app
How to cryptographically verify information from IAP to protect against spoofing
What you'll need
A modern web browser such as Chrome.
Basic knowledge of the Python programming language
This codelab is focused on Google App Engine and IAP. Non-relevant concepts and code blocks are glossed over and are provided for you to simply copy and paste.
2. Getting set up
You will work in the Cloud Shell command line environment. Start by opening that environment and fetching the sample code to it.
Launch the Console and Cloud Shell
Download the code
Click the command line area in the Cloud Shell so you can type commands. Fetch the code from Github and then change to the code folder:
git clone https://github.com/googlecodelabs/user-authentication-with-iap.git
Your Cloud Platform project in this session is set to uconn-engr.
Use “gcloud config set project [PROJECT_ID]” to change to a different project.
john_iacovacci1@cloudshell:~ (uconn-engr)$ git clone https://github.com/googlecodelabs/user-authenticatio
n-with-iap.git
Cloning into 'user-authentication-with-iap'...
remote: Enumerating objects: 22, done.
remote: Total 22 (delta 0), reused 0 (delta 0), pack-reused 22
Unpacking objects: 100% (22/22), done.
john_iacovacci1@cloudshell:~ (uconn-engr)$
john_iacovacci1@cloudshell:~ (uconn-engr)$ cd user-authentication-with-iap/
john_iacovacci1@cloudshell:~/user-authentication-with-iap (uconn-engr)$
This folder contains one subfolder for each step of this codelab. You will change to the correct folder to perform each step.
3. Step 1 - Deploy application and protect it with IAP
This is an App Engine Standard application written in Python 3.7
(note need to change app.yaml to runtime: python39)
App.yaml
runtime: python39
that simply displays a "Hello, World" welcome page. We will deploy and test it, then restrict access to it using IAP.
Review the application code
Change from the main project folder to the 1-HelloWorld subfolder that contains code for this step.
cd 1-HelloWorld
john_iacovacci1@cloudshell:~/user-authentication-with-iap (uconn-engr)$ cd 1-HelloWorld/
john_iacovacci1@cloudshell:~/user-authentication-with-iap/1-HelloWorld (uconn-engr)$
The application code is in the main.py file. It uses the Flask web framework to respond to web requests with the contents of a template. That template file is in templates/index.html, and for this step contains only plain HTML. A second template file contains a skeletal example privacy policy in templates/privacy.html.
There are two other files: requirements.txt lists all the non-default Python libraries the application uses, and app.yaml tells Google Cloud Platform that this is a Python 3.7 App Engine application. (note : need to change to python 3.9)
You can list each file in the shell using the cat command, as in:
cat main.py
Or you can open the Cloud Shell code editor by clicking the Pencil icon at the top right-hand side of the Cloud Shell window, and examine the code that way.
You do not need to change any files for this step.
Deploy to App Engine
Now deploy the app to the App Engine Standard environment for Python 3.9
gcloud app deploy
You may be asked to choose a region to deploy to. Select any one near to you that says it "supports standard". When you are asked if you want to continue, enter Y for yes.
In a few minutes the deploy should complete and you will see a message that you can view your application with gcloud app browse. Enter that command. If a new tab does not open in your browser, click the displayed link to open it in a new tab, or copy it to a manually opened new tab if necessary. Since this is the first time this app is run, it will take a few seconds to appear while a cloud instance is started, and you should see the following window.
john_iacovacci1@cloudshell:~/user-authentication-with-iap/1-HelloWorld (uconn-engr)$ gcloud app deploy
Services to deploy:
descriptor: [/home/john_iacovacci1/user-authentication-with-iap/1-HelloWorld/app.yaml]
source: [/home/john_iacovacci1/user-authentication-with-iap/1-HelloWorld]
target project: [uconn-engr]
target service: [default]
target version: [20210321t020740]
target url: [https://uconn-engr.uc.r.appspot.com]
Do you want to continue (Y/n)?
Beginning deployment of service [default]...
Created .gcloudignore file. See `gcloud topic gcloudignore` for details.
╔═════════════════════════════════════════════╗
╠═ Uploading 6 files to Google Cloud Storage ═╣
╚═════════════════════════════════════════════╝
File upload done.
Updating service [default]...done.
Setting traffic split for service [default]...done.
Deployed service [default] to [https://uconn-engr.uc.r.appspot.com]
You can stream logs from the command line by running:
$ gcloud app logs tail -s default
To view your application in the web browser run:
$ gcloud app browse
john_iacovacci1@cloudshell:~/user-authentication-with-iap/1-HelloWorld (uconn-engr)$
You can open that same URL from any computer connected to the Internet to see that web page. Access is not yet restricted.
Restrict access with IAP
What is Identity-Aware Proxy?
Identity-Aware Proxy (IAP) is a Google Cloud Platform service that intercepts web requests sent to your application, authenticates the user making the request using the Google Identity Service, and only lets the requests through if they come from a user you authorize. In addition, it can modify the request headers to include information about the authenticated user.
Fill in the required blanks with appropriate values:
No scopes needed
Click Save. You will be prompted to create credentials. You do not need to create credentials for this codelab, so you can simply close this browser tab.
You have successfully protected your app with IAP, but you have not yet told IAP which accounts to allow through.
Click Save. The message "Policy Updated" will appear at the bottom of the window.
Navigate back to your app and reload the page. You should now see your web app, since you already logged in with a user you authorized. However, you may still see the "You don't have access" page since IAP may not recheck your authorization. In that case, do the following steps:
Open your web browser to the home page address with /_gcp_iap/clear_login_cookie added to the end of the URL, as in https://iap-example-999999.appspot.com/_gcp_iap/clear_login_cookie.
You will see a new Sign in with Google screen, with your account already showing. Do not click the account. Instead, click Use another account, and re-enter your credentials.
These steps cause IAP to recheck your access and you should now see your application's home screen.
https://uconn-engr.uc.r.appspot.com/_gcp_iap/clear_login_cookie
If you have access to another browser or can use Incognito Mode in your browser, and have another valid GMail or GSuite account, you can use that browser to navigate to your app page and log in with the other account. Since that account has not been authorized, it will see the "You Don't Have Access" screen instead
Now apply a firewall rule to your application.
Go to app engine
Click on Firewall rules
A DoS firewall rule can be used to protect devices from denial-of-service (DoS) attacks by controlling traffic and applying DoS protection profiles:
Deny: Blocks traffic that matches the rule
Allow: Permits traffic that matches the rule
Protect: Applies a DoS protection profile to traffic that matches the rule
Creating App Engine firewall rules
bookmark_border
In App Engine, you can create a firewall with up to 1000 prioritized individual rules that either allow or restrict a range of IP addresses and subnets. Your app will only respond to requests that are allowed by the firewall.
To learn how the App Engine firewall works, see Understanding firewalls.
Before you begin
Before you can create App Engine firewall rules for your app, you must have one of the following App Engine IAM roles, which include the necessary privileges for creating or modifying firewall rules:
App Engine Admin
Editor
Owner
Creating firewall rules
Use one of the following methods to create a firewall rule. Repeat these steps for each additional rule:
Use the Firewall rules page in Google Cloud console to create a firewall rule:
Go to the Create a firewall rule page in Google Cloud console:
Go to the Create a firewall rule pageSpecify the details of the firewall rule:
In Priority, enter an integer to specify the relative importance of the rule and define the order of when the rule is evaluated.
Valid values are 1 to 2147483646. Priority 1 is the first rule evaluated. Priority 2147483647 is the last rule evaluated and is reserved for the `default` rule.
Important: After a rule is created, you cannot edit the priority value. You must delete and then recreate a rule to change the value of a rule's priority.In Action on match, specify whether to allow or deny access for requests that match the rule. Rules set to allow forward the request to the app. Rules set to deny respond to requests with a 403 Forbidden error.
In IP range, define the range of IP addresses that apply to the rule. The IP address range must be defined in CIDR notation, can include subnet masks, and support both IPv4 and IPv6.
Optional: In Description, include a description of the rule that is no longer than 100 characters.
Click Save to create the rule.
Test the rule to ensure that the priority and action provide the expected behavior:
Click Test IP address.
Enter the IP address that you want to validate and then click Test to ensure that the corresponding rule gets correctly evaluated.
Understanding App Engine firewall rules
An App Engine firewall consists of an ordered list of rules that can allow or deny access from the specified IP address or range to your app. The rule applies to all resources of the App Engine application.
Firewall rule priority
The firewall rules are ordered by importance, which you define as a numerical value in each rule's priority. You must specify a unique priority value for each rule as it defines the importance relative to the other rules in the firewall. The values for a rule's priority scale from the most important value of 1 up to the least important at value 2147483647.
Each firewall includes a default rule that is automatically created with the 2147483647 priority and applies to the entire IP range of your app. The default rule is always evaluated after all the other rules in the firewall and applied to all requests across all IP addresses.
The firewall evaluates the highest priority rule first. All the remaining rules in the firewall are sequentially evaluated until a rule matches the IP range of that request. When a matching rule is found, the connection is either allowed or denied, and all the remaining rules in the firewall are then skipped. If none of the manually defined rules in the firewall match the request, the default rule is evaluated.
For example, if you create a rule with priority 1 it is always evaluated first. If an incoming request matches the rule with priority 1, only that rule is evaluated and all the other rules in the firewall are skipped, including the default rule.
The example firewall below shows how a rule's priority can change the behavior of your firewall.
Note: If you set up port forwarding, remember that all requests through that forwarded port bypass the App Engine firewall.
Example firewall
In this example, a company has set up a firewall to grant access to the engineering team and internal corporate network to their in-development app. The firewall rules have been created with large gaps between each priority to allow for growth.
After the firewall is created, assume that the following requests are directed at the sample app and note the app's response:
Request from 198.51.100.2 matches rule with priority 2000 and is allowed.
Request from 198.51.100.100 matches rule with priority 3000 and gets denied.
Request from 203.0.113.54 matches rule with priority 5000 and is allowed.
Request from 45.123.35.242 matches the default rule and gets denied.
Resolving conflicting rules
For example, assume that two of the priorities in the company's firewall are swapped. If the rules for priorities 2000 and 3000 are swapped, notice the unintended behavior.
The engineer in the satellite office will not be able to access the company's app as the rule's new priority means it will never be evaluated. The engineer's IP address 198.51.100.2 matches the rule that denies all non-engineers in the range 198.51.100.0/24 before the rule that allows access to the engineer's IP address.
To fix this, you must set the priority of the rule that allows access to 198.51.100.2 to be higher than the rule that denies access for the IP range 198.51.100.0/24.
Create rule
A DoS firewall rule can be used to protect devices from denial-of-service (DoS) attacks by controlling traffic and applying DoS protection profiles:
Deny: Blocks traffic that matches the rule
Allow: Permits traffic that matches the rule
Protect: Applies a DoS protection profile to traffic that matches the rule
The command or statement "deny 192.0.2.1" is typically used in network security or firewall configurations. It specifies that traffic from or to the IP address 192.0.2.1 should be denied or blocked. This action can be configured in firewall rules, access control lists (ACLs), or other security policies.
Context: It could appear in settings for routers, switches, or firewalls to prevent communication with a specific device or network resource.
192.0.2.1: This IP address belongs to the "TEST-NET-1" block, which is reserved for documentation and examples (according to RFC 5737). It is not typically used in live networks.
So in real-world applications, a different IP would be used, but in examples, "deny 192.0.2.1" might illustrate how to deny access to a particular IP address.
Put in my email and send me link to app engine
No comments:
Post a Comment