Azure from scratch part 2 By Girish Kalamati

Intro & Setting up cloud
mind-Set
girishkrao.portfoliobox.net
theazureguys.wordpress.com
twitter.com/TheAzureGuy007
facebook.com/TheAzureGuy007
https://github.com/TheAzureGuy007
https://www.linkedin.com/in/girish-kalamati-357a6398/
https://www.youtube.com/channel/UCd9z6-2mZdqjRnAHh3W_9Uw

Azure Active Directory (AAD) Overview
Azure Active Directory is a multi tenant, cloud based directory and identity management system.
It is a Platform as a Service (PaaS) Offering and facilitates a lot of different functionality, some of which are
• Single-Sign-On across multiple applications in Software-as-a-Service (SaaS) offerings
• Multi-Factor Authentication
• Role-based access control (RBAC)
• Device Registration

It is not the same platform as on-premises Active Directory Domain Services (AD DS).
It does not have
• Group Policy for managing users and computers
• Does not have Organizational Units. It is a flat organizational structure
• There are no forests or trusts. Federation is used to allow outside of boundary authentication and authorization
Integration with AAD into your On-premises Active Directory is possible (hybrid infrastructure)
You can leverage some of the benefits of cloud based identities within your organization (single-sign-on with
Office 365)
Authentication
Azure Active Directory (Azure AD) supports several authentication and authorization protocols. (OAuth 2.0, OpenID
Connect, WS-Federation, or SAML 2.0.)
Note: Kerberos is not supported as in On-PremAD

These are the five primary application scenarios supported by Azure AD:
• Web Browser to Web Application: A user needs to sign in to a web application that is secured by Azure AD.
• Single Page Application (SPA): A user needs to sign in to a single page application that is secured by Azure AD.
• Native Application to Web API: A native application that runs on a phone, tablet, or PC needs to authenticate a user to
get resources from a web API that is secured by Azure AD.
• Web Application to Web API: A web application needs to get resources from a web API secured by Azure AD.
• Daemon or Server Application to Web API: A daemon application or a server application with no web user interface
needs to get resources from a web API secured by Azure AD.

Web Browser to Web Application
Application that authenticates a user in a web browser to a web application.

https://github.com/TheAzureGuy007/active-directory-dotnet-webapp-multitenant-
openidconnect/tree/TheAzureGuy007
Demo

<add key="ida:ClientID" value="6b5ac887-0233-412b-9e31-cceb2f439ca3"/>

<add key="ida:Password" value="2lDfXrh3UFYqXvQy0+36SJSh+yxkVn1nG17woKGBrH4=" />

Single Page Application (SPA)
Single Page Applications are typically structured as a JavaScript presentation layer (front end) that runs in the
browser and a Web API back end that runs on a server and implements the application’s business logic.

https://github.com/TheAzureGuy007/active-directory-angularjs-singlepageapp/tree/TheAzureGuy007
Demo

Native Application to Web API
Native application that calls a web API on behalf of a user, The native application obtains an access token for the user by usin
the OAuth 2.0 protocol. This access token is then sent in the request to the web API.

https://github.com/TheAzureGuy007/active-directory-dotnet-native-desktop/tree/TheAzureGuy007
Demo

Web Application to Web API
Web application that needs to get resources from a web API
Application identity:
Web API can only detect that the web application
is calling it, as the web API does not receive any
information about the user.
If the application receives information about the
user, it will be sent via the application protocol,
and it is not signed by Azure AD.
The web API trusts that the web application
authenticated the user.
For this reason,
this pattern is called a trusted subsystem.

Web Application to Web API
Web application that needs to get resources from a web API
Delegated user identity:
This scenario can be accomplished in two ways:
OpenID Connect, and OAuth 2.0 authorization
code grant with a confidential client.
The web application obtains an access token for
The user, which proves to the web API that the
user successfully authenticated to the web
application and that the web application was
able to obtain a delegated user identity to call
the web API.
This access token is sent in the request to the
web API, which authorizes the user and returns
the
desired resource.

https://github.com/TheAzureGuy007/active-directory-dotnet-webapp-webapi-multitenant-openidconnect/tree/TheAzureGuy007
Demo

Daemon or Server Application to Web APIDaemon or server application(Web API) that needs to get resources from a web API
Daemon application needs to call a web API :
An example of a daemon application is a batch job, or an operating system service running in the background.
This type of application requests an access token by using its application identity and presenting its Application ID, credential
(password or certificate), and application ID URI to Azure AD.
After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.

Daemon or Server Application to Web APIDaemon or server application(Web API) that needs to get resources from a web API
Server application (WebAPI) needs to call a web API :
Imagine that a user has authenticated on a native application, and this native application needs to call a web API.
Azure AD issues a JWT access token to call the web API. If the web API needs to call another downstream web API,
it can use the on-behalf-of flow to delegate the user’s identity and authenticate to the second-tier web API.

https://github.com/TheAzureGuy007/active-directory-dotnet-daemon/tree/TheAzureGuy007
Demo

Multi-tenant SaaS application & Azure SQL DB

Azure AD Subscription Models
Azure AD effectively comes in four different subscription models, the free edition which is available by
default when you sign up for one of several services.
Free:
Directory Objects
User/Group Management (add/update/delete)/ User-based provisioning, Device registration
Self-Service Password Change for cloud users
Connect (Sync engine that extends on-premises directories to Azure Active Directory)
Single-Sign-On
Security / Usage Reports
Self Service Password reset for cloud administrators only
Basic:
No Object Limit
Ability to use your own company branding
Self Service password reset/change/unlock for cloud users and cloud administrators only
Has Application proxy available
Has an SLA of 99.9%

Premium P1
No Object limit
Self Service password reset/change/unlock for any user
MFA Cloud and on-premises
Connect Health
Microsoft Identity manager user CALs
Premium P2
No Object limit
Self Service password reset/change/unlock
MFA Cloud and on-premises
Connect Health
Microsoft Identity manager user CALs
Identity protection
Privileged Identity Management
Azure AD Subscription Models

Manage Users and Groups in Azure AD
There are several tasks and tools that you can use to manage users and groups in Azure AD.
General tasks for users and /or groups include:
Creation
Editing
Deletion
Managing group member ship
Resetting user passwords.
Tools that can be used to accomplish these tasks include:
Azure Portal
Classic Portal
Windows PowerShell
Bulk creation and editing using .csv file

Manage Users & Groups in Azure AD

Manage Multiple AAD Directories and Tenants

What is Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) is the ability to require additional authentication for
on-premises or cloud services and applications. It requires the use of more than one
verification system:
Something you know (typically a password)
Something you have (a trusted device, such as a phone or smartcard)
Something you are (biometrics)
In addition to your traditional user name and password MFA will require additional
authentication associated with one of the following from the user looking to access
the service or application:
Mobile application,
A phone call
A text message
An email message
Third party OAuth token

Azure Multi-Factor Authentication is available as a stand-alone service with per user and per authentication
billing options, or bundled with Azure Active Directory Premium, Enterprise Mobility Suite or Enterprise
Cloud Suite.

If your users do not regularly sign in through the browser, you can send them to
this link to register for multi-factor auth: https://aka.ms/MFASetup

There are a number of ways that you can extend your on-premises infrastructure into Azure. As such you need to
analyze what your business requirements are, what are you trying to achieve by extending your infrastructure into
Microsoft Azure, and what are the needs of the those various elements such as users, internal and customers,
applications and your infrastructure.
Extend on-premises AD into Azure
• Involves running a Domain Controller in Azure in a virtual machine using Azure IaaS
• Would typically be done .to support some applications in Azure, to fulfill a requirement to have Domain
Controller availability in a remote part of the world, or perhaps to run a secondary site for recovery operations
Synchronize Active Directory Domain Services (AD DS) with Azure AD
• Will put a copy of your credentials in Azure
• Would typically be when investing in Office 365, Microsoft Intune or Microsoft Dynamics and to allow users login
into those cloud based apps with their domain credentials.
Implement a federated Trust relationship with Azure AD
• Credentials only exists in your on-premises AD and Azure AD trusts your on-premises credentials using claims.
• Requires the installation of Active directory federation Services (AD FS)
• Create a direct trust relationship with Azure AD and on-premises Active Directory using ADFS
• Probably the most complex implementation, and we won't look at it in detail in this course, but would retain all
your credentials in your on-premises environment, giving you the greatest level of isolation.
Implementing Hybrid AD Solutions

https://docs.microsoft.com/en-us/azure/active-
directory/active-directory-install-replica-active-directory-
domain-controller

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-implement-
password-synchronization

AD + AAD Connector + ADFS + AAD

Synchronization with Azure AD Connect
Azure AD Connect allows you to synchronize your on-premises Active Directory directories with Azure AD. This
will then allow you to use a common identity for your users to use with Office 365, Microsoft Intune, and other
SaaS applications and on-premises applications, providing a single credential to be across both, allowing for
Single-Sign-On (SSO).
Azure AD Connect also provides administrative benefits, providing for alerts and monitors, as well as password
synchronization.
Using Azure AD Connect is the simplest way to extend your on-premises directories to Azure to provide SSO with
SaaS applications such as Office 365.

Azure AD Connect Health
Azure AD Connect Health allows you to monitor the
health of your on-premises infrastructure and the
connectivity and synchronization between your on-
premises environment and Azure AD.
It allows you to monitor your identity servers including
AD Domain Controllers and AD FS server.
A health agent needs to be installed on those identity
servers to allow for health monitoring.
Azure AD Connect can also be used to monitor your
on-premises AD FS infrastructure.

Integrating Azure AD and SaaS Applications
Identity and Access management (IAM) can be defined as getting the right people, access to the right
application or service, at the right times, for the right reasons.
Stop using multiple credentials, Have only 1 singe AAD auth to access multiple apps from different
vendors.
People may also be spending time looking for application to do a particular job without realizing
what applications your organization already has licenses for.
Azure AD integration with SaaS applications provides
• Centralized identity and access management
• Ability to manage application licenses
• Single-Sign-On across multiple applications
• Reporting
• Access to over a thousand applications in the application gallery such as Office 365, Facebook, DropBox,
Salesforce etc.
• The ability to customize and add your own applications to the gallery.
Finding unmanaged cloud applications with Cloud App Discovery

Federation Overview
As cloud based applications become more prevalent, and the services that people use become more
essential in their day to day living and work, the questions arises how to manage those different
identity resources and applications across both business and partner situations, as well as consumer
use scenarios. Lets define a couple of core terms that come into play in this area.
Claims
Claims are statements, or assertions, about the identity of an object made by an issuer, or an identity
provider, such as Windows Server Active Directory, or Azure Active Directory, or even another 3rd
party such as Facebook. Identity claims are presented to applications using a Security Token Service
(STS) and if the issuer of the claim is trusted by the application, access is then granted .
Federated Trusts
Federated Trusts are a mechanism for enabling Single-Sign-On (SSO) across different identity
domains. It is a means of authenticating identities in a different domain without having those
credentials available in that different domain. It thus allows you to validate users without having
access to the credentials, once a trust is in place between your identity domain and the identity
domain requesting access to whatever the resource is.

portal.office.com
Smart Card or RAS card authentication
Normal Windows Dialog auth

For an internal user (see diagram above):
1. An internal user accesses claims aware
application
2. The application redirects the user to the AD FS
server
3. The AD FS server authenticates the user and
performs an HTTP post to the application where the
user gains access
Note: The redirects are performed using a
standard HTTP 302 Redirect.
The posts are performed using a standard HTTP
POST.
How does the AD FS 2.0 Proxy Work for Internal Users

For an external user (see diagram above):
1. An external user accesses claims aware
application
2. The application redirects the user to the AD FS 2.0
proxy server
3. The proxy server connects to the internal AD FS
server and the AD FS server authenticates the user
4. The AD FS 2.0 proxy performs an HTTP Post to the
application where the user gains access
Note: Depending on the infrastructure configuration,
complexity, protocol, and binding the traffic flow can
vary.
How does the AD FS 2.0 Proxy Work for External Users

Azure AD B2C
What is Azure AD B2C?
Azure AD B2C is a cloud identity
management solution for your consumer-
facing web and mobile applications.

Azure B2C
8a8f*******************88f2283072f
APP_Key: J.***************
Facebook Developer Analytics:
https://developers.facebook.com/apps/1531308103557288/dashboard/
v2.10
153************88
4c***********************491f8
https://console.developers.google.com/apis/library?authuser=2
Google:
https://console.developers.google.com/apis/dashboard
4666*********************************v.apps.googleusercontent.com
4l***************b
https://developer.linkedin.com/docs/oauth2#
LinkedIn:
https://www.linkedin.com/developer/apps/5054385/auth
81f********m28
2dx************u3p
Microsoft
https://apps.dev.microsoft.com/
8348b35a-4ef9-4ec4-b428-ec98ab373ce7
jqSetvyqSVn2qbXyA9wenrA
Demo
https://github.com/TheAzureGuy007/ac
tive-directory-b2c-dotnet-webapp-and-
webapi/tree/TheAzureGuy

Integrating Ping Identity and B2C app in Azure AD

Converts OpenId auth from AAD to HTTP header auth in
PIngAccess

1.The user accesses the application through the Application Proxy service and is
directed to the Azure AD sign-in page to authenticate.
2.After a successful sign-in, a token is generated and sent to the client device.
3.The client sends the token to the Application Proxy service, which retrieves the user
principal name (UPN) and security principal name (SPN) from the token, then directs the
request to the Application Proxy connector.
4.If you have configured single sign-on, the connector performs any additional
authentication required on behalf of the user.
5.The connector sends the request to the on-premises application.
6.The response is sent through Application Proxy service and connector to the user.

Configure your applications to use PingAccess for Azure AD with just four steps:
1.Configure Azure AD Application Proxy Connectors
2.Create an Azure AD Application Proxy Application
3.Download & Configure PingAccess
4.Configure Applications in PingAccess

Authentication and Access Flow Use Case
1. User makes application request (attempts to access on prem app) and Azure AD Application Proxy routes request
to PingAccess.
2. PingAccess checks for existence of active web session.
3. PingAccess redirects to Azure AD for SSO authentication. User signs on via Azure AD. Since the user would’ve
already signed on,
they’ll get SSO. Azure AD will issue a token for PingAccess.
4. Browser is redirected back to PingAccess with OIDC token which PingAccess validates.
5. PingAccess session is created and access is granted.
6. Application request is forwarded to the protected application with identity information in HTTP request header.

Install an Application Proxy connector
Prerequisites:
1) Microsoft Azure AD basic or premium subscription & Azure AD
directory for which you are a global administrator
2) Windows Server 2012 R2 or 2016 (Application Proxy Connector
should be able to connect to Application Proxy services in the cloud
Add your app to Azure AD with Application Proxy
1) you need to publish your application with Application Proxy.
2) you need to collect some information about the app that you can
use during the PingAccess steps.
1) Open your ports
2) If your firewall or proxy allows DNS whitelisting,
you can whitelist connections to msappproxy.net and
servicebus.windows.net. If not, you need to allow access to
the Azure DataCenter IP ranges, which are updated each wee
3) Microsoft uses four addresses to verify certificates.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
4) Your connector needs access to login.windows.net
and login.microsoftonline.net for the registration process.
Use the Azure AD Application Proxy Connector Ports
Test Tool to verify that your connector can reach the
Application Proxy service. At a minimum, make sure
that the Central US region and the region closest to you
have all green checkmarks. Beyond that, more green
checkmarks means greater resiliency.
Port
number How it's used
80 Downloading certificate revocation lists (CRLs) while
validating the SSL certificate
443 All outbound communication with the Application Proxy
service

Collect information for the
PingAccess steps
Download PingAccess
and configure your app
Configure PingAccess for Azure AD

Collect information for the
PingAccess steps
Download PingAccess
and configure your app
Configure PingAccess for Azure AD
• Configure PingAccess to use Azure AD as the token
provider
• Configure a PingAccess application for each
application you want to protect and make available to
Azure AD as part of this solution. Applications require
configuration of:
• A virtual host
• A web session
• An identity mapping
• A site
• An application
When the configuration is complete, you can test the

Once the connector problem (Ports issues) fixes up

PingTestApp,Application ID/Client ID - 883fba60-1df4-4bb2-8278-9b0209944ca3
Key_1 : +HRw75njdFxxrFIYnAImoVcurC9MeugCkvDhqamos2U=

Federated Auth Aproach :
Federate your Azure AD with PingFederate and use Azure AD' OpenIDConnect protocol to configure single sign on for your
cloud application
1) Sign-up for a free trial Azure subscription and create a directory.
2) sample app (https://github.com/AzureADSamples/WebApp-OpenIDConnect-DotNet) to connect your app' authentication
with your directory using OpenIDConnect.
3) Then, add a verified domain to your directory and federate it with your PingFederate STS by following the guidance
here (http://documentation.pingidentity.com/display/PFS/SSO+to+Office+365+Introduction)

PingID SAML IdP in Azure AD B2C (Custom Policies)
https://docs.microsoft.com/en-us/azure/active-directory-
b2c/active-directory-b2c-get-started-custom
https://docs.pivotal.io/p-identity/1-2/pingfederate/config-
pingfederate.html
1) PING ID free trial for integration

Inheritance model
When an Application -----calls--- RP Policy file,
the Identity Experience Framework in B2C will -----add all the elements from
BASE-- then from EXTENSIONS -----and lastly from the RP policy file to-
assemble the current policy in effect. Elements of the same type and name in
the RP file will override those in the EXTENSIONS, and EXTENSIONS
overrides BASE.
Built-in policies in Azure AD B2C follow the 3-file pattern depicted above,
but the developer only sees the Relying Party (RP) file, while the portal
makes changes in the background to the EXTenstions file. All of Azure AD
B2C shares a BASE policy file that is under the control of the Azure B2C
team and is updated frequently.

Setup configuration at PingFederate End:
https://docs.pivotal.io/p-identity/1-3/pingfederate/config-pingfederate.html
PingFederate Server 8.4.1 - Windows
Download & Install
Step 1
For proper installation, download PingFederate Server to
the same server or domain where your user store is
located.
Download
Step 2
Run the PingFederate Server installer and follow the
steps. When complete, you'll be provided with the URL for
your PingFederate Server admin console.

Instruction for installing PinGFederate
https://documentation.pingidentity.com/pingfederate/pf83/index.shtml#gettingStartedGu
ide/concept/installation.html
Setting Java Environmental Variables before installing PinGFederate
https://docs.pingidentity.com/bundle/paaad_sm_InstallPingAccess_paaad43/page/pa_t_I
nstalling_PingAccessWindows.html#Install_PingAccess_unique_1

Get the Activation Key to Join PingFederate with PingOne: TLOUzHjDY3o1GsDgoJ2J9l40EnPWmP

Basic Info
https://pingidcptestvm:9031
urn:saml2:zen3

New User PingOne
Email: girish.k@zen3.com
Username: girish_Kalamati
PWD: Girish@#123

Get Started
https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-
directory-b2c-get-started-custom
directory-b2c-overview-custom#policy-files
Setup Active Dir
directory-b2c-setup-aad-custom

Azure Active Directory B2C MSAL (Microsoft Authentication Library)
Obtain tokens from Active Directory, Azure Active
Directory B2C, and MSA for accessing protected
resources

https://docs.pingidentity.com/bundle/pf_sm_createAnOpenidConnectIdpConnection_pf83/page/pf_t_createAnOpenidConn
ectIdpConnection.html?#
https://docs.pingidentity.com/bundle/pf_sm_pingfederateOauth20Endpoints_pf82/page/concept/openIdConnectMetadataE
ndpoint.html

A 'Simple' PCV (Password Credential Validator)
https://docs.pingidentity.com/bundle/pf_sm_simpleUsernamePasswordCredentialValidator_topic/page/conc
ept/configuringTheSimpleCredentialValidator.html?#

However, Azure Active Directory Premium subscriptions include a basic PingAccess
license that covers up to 20 applications.

How do I get access?
Since this scenario is offered through a partnership between Azure Active Directory and PingAccess,
you need licenses for both services.
* However, Azure Active Directory Premium subscriptions include a basic PingAccess license that covers
up to 20 applications.
* If you need to publish more than 20 header-based applications, you can purchase an additional license
from PingAccess.

Modern Applications and Requirements
Modern Applications
The world of applications has changed drastically from what it was a decade ago. What constitutes an application
can take on a number of different forms such as
• API and Logic applications
• Mobile applications
• Web applications
• Function based applications
Requirements
The speed of development and
deployment has also changed as
business and customer requirements
have changed.
Deeper engagement with customers
• Faster times to market
• Scalability
• Availability
All of which needs to be done under continuous cost pressures in a global market.

App Service plans define the capabilities and boundaries for the environment in which you want your application
to run.
There are five layers available from which you can choose
Free
Shared
Basic
Standard
Premium
1 Application >> can only be a member of >> 1 Service Plan
1 Service plan >> can have multiple applications associated with it
Note: Application must be in the same subscription and geographic location can share a plan and all the apps
that share a plan can use all the capabilities and features that are defined by the plan's tier.
App Service Plan

App Service Environment - Private Infrastructure

App Service Environment - Private Infrastructure
Pool 3 Worker Large
Instances
Pool 2 Worker
Medium Instances
Pool 1 Worker small
instances

If u have this kind of private app service stamps you can
build lot secure* SaaS Application for your
internal/external customers
*Secure- You only have access to Your App service Environment even it is shared Multi-
tenant service

Azure App Services Overview
Azure App Service consists of Five main components
• Web apps: web based applications that can scale with business requirements
• Mobile Apps: mobile applications that can run on any device
• Logic apps: For automating business processes and integrating systems and data across clouds without writing
code.
• API apps: For hosting RESTful APIs that other services can leverage, such as in IoT scenarios
• Functions: Event based development and deployment, allowing you to define functions that trigger specific
events in App Services, such as spinning up an application under specific circumstances, reducing overall costs.

Why use App Service?
Multiple languages and frameworks - App Service has first-class support for ASP.NET, Node.js, Java, PHP, and
Python. You can also run Windows PowerShell and other scripts or executables on App Service VMs.
DevOps optimization - Set up continuous integration and deployment with Visual Studio Team Services, GitHub, or
BitBucket. Promote updates through test and staging environments. Perform A/B testing. Manage your apps in
App Service by using Azure PowerShell or the cross-platform command-line interface (CLI).
Global scale with high availability - Scale up or out manually or automatically. Host your apps anywhere in
Microsoft's global datacenter infrastructure, and the App Service SLA promises high availability.
Connections to SaaS platforms and on-premises data - Choose from more than 50 connectors for enterprise
systems (such as SAP, Siebel, and Oracle), SaaS services (such as Salesforce and Office 365), and internet services
(such as Facebook and Twitter). Access on-premises data using Hybrid Connections and Azure Virtual Networks.
Security and compliance - App Service is ISO, SOC, and PCI compliant.
Application templates - Choose from an extensive list of templates in the Azure Marketplace that let you use a
wizard to install popular open-source software such as WordPress, Joomla, and Drupal.
Visual Studio integration - Dedicated tools in Visual Studio streamline the work of creating, deploying, and
debugging.

Azure App Service plans overview
App Service plans represent the collection of physical resources used to host your apps.
App Service plans define:
• Region (West US, East US, etc.)
• Scale count (one, two, three instances, etc.)
• Instance size (Small, Medium, Large)
• SKU (Free, Shared, Basic, Standard, Premium)
-> Web Apps, Mobile Apps, Function Apps, or API Apps, in Azure App Service all run in an App Service plan.
Apps in the same subscription and region and resource group can share an App Service plan.
All applications assigned to an App Service plan share the resources defined by it allowing you to save cost when
hosting multiple apps.
-> Your App Service plan can scale from Free and Shared SKUs to Basic, Standard, and Premium SKUs giving you
access to more resources and features along the way.
-> If your App Service plan is set to Basic SKU or higher you can control the size and scale count of the VMs.
For example, if your plan is configured to use two "small" instances in the standard service tier, all apps that are
associated with that plan run on both instances. Apps also have access to the standard service tier features.
Plan instances on which apps are running are fully managed and highly available.
-> The SKU and Scale of the App Service plan determines the cost and not the number of apps hosted in it.
Visit the App Service Pricing web page for the latest pricing and capabilities of each service plan.

Azure App Service, Virtual Machines, Service Fabric,
and Cloud Services comparison
Azure offers several ways to host web sites: Azure App Service, Virtual Machines, Service Fabric, and Cloud Services.
Azure App Service is the best choice for most web apps.
* Deployment and management are integrated into the platform, sites can scale quickly to handle high traffic
loads, and the built-in load balancing and traffic manager provide high availability.
* You can move existing sites to Azure App Service easily with an online migration tool, use an open-source app
from the Web Application Gallery, or create a new site using the framework and tools of your choice.
* The WebJobs feature makes it easy to add background job processing to your App Service web app.
Service Fabric is a good choice if you’re creating a new app or re-writing an existing app to use a microservice
architecture.
* Apps, which run on a shared pool of machines, can start small and grow to massive scale with hundreds or
thousands of machines as needed.
* Stateful services make it easy to consistently and reliably store app state, and Service Fabric automatically
manages service partitioning, scaling, and availability for you.
* Service Fabric also supports WebAPI with Open Web Interface for .NET (OWIN) and ASP.NET Core.
-> Compared to App Service, Service Fabric also provides more control over, or direct access to, the underlying infrastructure.
-> You can remote into your servers or configure server startup tasks.
-> Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service
Fabric is recommended for new development.

Key App Service Features for Mobile Apps
Auto Scaling - App Service enables you to quickly scale-up or out to handle any incoming customer
load. Manually select the number and size of VMs or set up auto-scaling to scale your mobile app
backend based on load or schedule.
Staging Environments - App Service can run multiple versions of your site, allowing you to perform
A/B testing, test in production as part of a larger DevOps plan and do in-place staging of a new
backend.
Continuous Deployment - App Service can integrate with common SCM systems, allowing you to
automatically deploy a new version of your backend by pushing to a branch of your SCM system.
Virtual Networking - App Service can connect to on-premises resources using virtual network,
ExpressRoute or hybrid connections.
Isolated / Dedicated Environments - App Service can be run in a fully isolated and dedicated
environment for securely running Azure App Service apps at high scale. This is ideal for application
workloads requiring very high scale, isolation or secure network access.

Implementing Mobile Apps
https://azure.microsoft.com/en-us/documentation/learning-paths/appservice-mobileapps/
https://docs.microsoft.com/api/Redirect/en-us/documentation/articles/app-service-mobile-ios-get-
started/

API Apps Overview
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and
on-premises.
With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK
generation, and seamless integration with Logic Apps.

API Apps Overview
API Management is about managing APIs. You put an API Management front end on an API to monitor and throttle usage,
manipulate input and output, consolidate several APIs into one endpoint, and so forth. The APIs being managed can be hosted
anywhere.
API Apps is about hosting APIs. The service includes features that facilitate developing and consuming APIs, but it doesn't do
the kinds of monitoring, throttling, manipulating, or consolidating that API Management does. If you don't need API
Management features, you can host APIs in API apps without using API Management.

Implementing API App
https://docs.microsoft.com/en-us/azure/app-service-api/app-service-api-dotnet-get-started

Implementing API App (Use Swagger API metadata and UI)

Implementing API App (Add Rest API Client)

As you did for Data Tier carry out for Middle Tier Configure the middle tier to call the data tier

(Configuring Middle-Tier)

Key App Service Features for API Apps
Bring your existing API as-is - You don't have to change any of the code in your existing APIs to take
advantage of API Apps -- just deploy your code to an API app. Your API can use any language or
framework supported by App Service, including ASP.NET and C#, Java, PHP, Node.js, and Python.
Easy consumption - Integrated support for Swagger API metadata makes your APIs easily consumable
by a variety of clients. Automatically generate client code for your APIs in a variety of languages
including C#, Java, and JavaScript. Easily configure CORS without changing your code.
Simple access control - Protect an API app from unauthenticated access with no changes to your
code. Built-in authentication services secure APIs for access by other services or by clients representing
users. Supported identity providers include Azure Active Directory, Facebook, Twitter, Google, and
Microsoft Account. Clients can use Active Directory Authentication Library (ADAL) or the Mobile Apps
SDK.
Visual Studio integration - Dedicated tools in Visual Studio streamline the work of creating,
deploying, consuming, debugging, and managing API apps.
Integration with Logic Apps - API apps that you create can be consumed by App Service Logic Apps.

Logic Apps Overview
Logic Apps provide a way to simplify and
implement scalable integrations and
workflows in the cloud.
It provides a visual designer to model and
automate your process as a series of steps
known as a workflow.
There are many connectors across the
cloud and on-premises to quickly integrate
across services and protocols.
A logic app begins
with a trigger
(like 'When an
account is added to
Dynamics CRM') and
after firing can begin
many combinations
actions, conversions,
and condition logic.

Implementing Logic App
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-create-a-logic-app

Few more Logic App implementations -
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-create-a-logic-app

Staging Environments in App Service
Avoid “COLD START”

Deploying your application to a deployment slot has the following benefits:
• You can validate app changes in a staging deployment slot before swapping it with the production
slot.
• Deploying an app to a slot first and swapping it into production ensures that all instances of the slot
are warmed up before being swapped into production. This eliminates downtime when you deploy your
app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. This
entire workflow can be automated by configuring Auto Swap when pre-swap validation is not needed.
• After a swap, the slot with previously staged app now has the previous production app. If the changes
swapped into the production slot are not as you expected, you can perform the same swap
immediately to get your "last known good site" back.
Staging Environments in App Service

Azure App Service Deployment Overview
Azure App Service maintains the application framework
for you (ASP.NET, PHP, Node.js, etc). Some frameworks
are enabled by default while others, like Java and
Python, may need a simple checkmark configuration to
enable it.
Since you don't have to worry about the web server or
application framework, deploying your app to App
Service is a matter of deploying your code, binaries,
content files, and their respective directory structure, to
the /site/wwwroot directory in Azure (or the
/site/wwwroot/App_Data/Jobs/ directory for WebJobs).
App Service supports the following deployment
options:
FTP or FTPS: Use your favorite FTP or FTPS enabled tool
to move your files to Azure, from FileZilla to full-
featured IDEs like NetBeans. This is strictly a file upload
process. No additional services are provided by App
Service, such as version control, file structure
management, etc.

Kudu (Git/Mercurial or OneDrive/Dropbox):
• Use the deployment engine in App Service.
• Push your code to Kudu directly from any
repository.
• Kudu also provides added services whenever
code is pushed to it, including version control,
package restore, MSBuild, and web hooks for
continuous deployment and other automation
tasks.
• The Kudu deployment engine supports 3
different types of deployment sources: Content
sync from OneDrive and Dropbox; Repository-
based continuous deployment with auto-sync
from GitHub, Bitbucket, and Visual Studio Team
Services; and Repository-based deployment
with manual sync from local Git.

Web Deploy:
Deploy code to App Service directly from your
favorite Microsoft tools such as Visual Studio using
the same tooling that automates deployment to
IIS servers.
• This tool supports diff-only deployment,
database creation, transforms of connection
strings, etc.
• Web Deploy differs from Kudu in that
application binaries are built before they are
deployed to Azure. Similar to FTP, no additional
services are provided by App Service.

What is Kudu?
Kudu is the engine behind source control based deployments into Azure App Service. Regardless of what
deployment option is used however there are management capabilities available for your web sites using
Kudu.
It can provide useful management information environment variables, you can upload files and folders using
drag and drop, can take a diagnostic dump, view log files and more, and can let you access and view your
Web App folder structure within the browser via a built in console.

https://github.com/TheAzureGuy007/The-Azure-Guy-Repo/blob/master/AppCode.zip

What is Continuous Deployment?
Azure App Service integrates with BitBucket, GitHub, and Visual Studio Team Services (VSTS) and
enables a continuous deployment workflow where Azure pulls in the most recent updates from
your project published to one of these services. Continuous deployment is a great option for
projects where multiple and frequent contributions are being integrated.

Demo: Lets Trigger a Build using our 1st CD setup

Note: while u r done with the process of CD you will see a VSTS account created in your visualstudio.com account

Demo: Lets Build our VSTS code with Jenkins
https://www.visualstudio.com/en-us/docs/marketplace/integrate/service-hooks/services/jenkins

https://jenkins.io/blog/2017/04/20/secure-jenkins-on-azure/
Add InBound Rule for Port 8080 which is not allowed by
default

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Note: You need to add a user with different emal-id (not
VSTS email-id ) to Jenkin, admin user credentials wont
work out & create Git –Credentials @VSTS before hand
otherwise build will fail

Note: Provide the Jenkins Base Url with port no. & Check
Build when change is pushed to Team services (VSTS)

Azure from scratch part 2 By Girish Kalamati

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Azure from scratch part 2 By Girish Kalamati

Similar a Azure from scratch part 2 By Girish Kalamati (20)

Último

Último (20)

Azure from scratch part 2 By Girish Kalamati