An Architect's vision

Types Key Value Store Column Store Document Store Graph Database Performance   High High High Variable Scalability High High Variable (High) Variable Flexibility   High Moderate High High Complexity   None Low Low High Read Consistent Read   Read rare Read Intensive   More Read Intensive Write   Consistent Write Write Many   Not write Intensive Less Write Intensive Others Caching User Session Caching Contents   IOT Quick stream OS Handle lots of variety of data Data Type may relate each other Vertical Scaleout Horizontal Scaleout

Name NoSQL - Column Store RDBMS - Columnar Description Wide-column store based on Apache Hadoop and on concepts of BigTable Columnar RDBMS optimized for Big Data analytics Database model Wide column store Relational DBMS  Data scheme schema less yes Typing  no yes Secondary indexes no yes SQL  no yes Server-side scripts  yes  yes Triggers yes yes Partitioning methods  Sharding shared disk or shared nothing architectures with SAP IQ Multiplexer MapReduce  yes no Consistency concepts  Immediate Consistency Immediate Consistency Foreign keys  no yes Transaction concepts  no ACID Concurrency  yes yes Durability  yes yes User concepts Access Control Lists (ACL)  fine grained access rights according to SQL-...

  Hadoop is a computing framework where as NoSQL is Not Only - SQL databases Hadoop refers to an ecosystem of software packages, including MapReduce, HDFS, and a whole host of other software packages to support the import and export of data into and from HDFS (the Hadoop Distributed FileSystem). NoSQL is referring to non-relational or at least non-SQL database solutions such as HBase (also a part of the Hadoop ecosystem), Cassandra, MongoDB, Riak, CouchDB, and many others. Apache Hadoop is an open-source software framework that supports data-intensive distributed applications, licensed under the Apache v2 license.1 It enables applications to work with thousands of computational independent computers and petabytes of data. In computing, NoSQL (mostly interpreted as "not only SQL"1) is a broad class of database management systems identified by its non-adherence to the widely used relational database management system model; that is, NoSQL d...

There are three types of SSL Certificate available today; Extended Validation (EV SSL), Organization Validated (OV SSL) and Domain Validated (DV SSL). The encryption levels are the same for each certificate, what differs is the vetting and verification processes needed to obtain the certificate and the look and feel of in the browser address bar.

A CSR . A   certificate signing request or CSR   is a piece of text that must be generated on your web server before ordering the SSL certificate. The certificate authority will use the information contained in the CSR (Organization name, domain name, public key, etc...) to create your certificate.

We need the following information to generate a Certificate Signing Request (CSR): For the SSL Cert.   1.       Hostname: (this is your domain name with or without the www, the ssl will only work one way or the other.)   2.       Email Address 3.       Street Address 4.       Country (2 letter abbrev) 5.       State (no abbrev) 6.       City 7.       Postal Code   8.       Company 9.       Division 10.   Password (of your choosing)  

1.       A browser or server attempts to connect to a Website . Web server, secured with SSL.   2.       The browser/server requests that the Web server identify itself. The Web server sends the browser/server a copy of its SSL certificate and Public Key 4.       Web Brower has list of trusted certificate authorities 5.       Web server responds by sending a certificate. Server responds by sending a copy of its   SSL   Certificate, including the server's public key. 6.       Web browser checks the certificate and verify whether the certificate is issued by one of it’s trusted security certificate authorities. The browser/server checks to see whether or not it trusts the SSL certificate. If so, it sends a message to the Web server. The Web server sends back a digitally signed acknowledgement to start ...

There are several advantages of deploying AD FS in Azure, a few of them are listed below: High Availability   - With the power of Azure Availability Sets, you ensure a highly available infrastructure. Easy to Scale   – Need more performance? Easily migrate to more powerful machines by just a few clicks in Azure Cross-Geo Redundancy   – With Azure Geo Redundancy you can be assured that your infrastructure is highly available across the globe Easy to Manage   – With highly simplified management options in Azure portal, managing your infrastructure is very easy and hassle-free

Web Application Proxy   (WAP), is a remote access computer software feature in Windows Server 2012 R2. It replaced Microsoft Forefront Unified Access Gateway (UAG). WAP provides the reverse   proxy   capability that allows users outside a corporate network to access web applications   hosting on the internal corporate network.  

The web application is called a "client" because it initiates the request to the authorization server (AD FS) for an access token to the resource. The resource may be hosted by the web app itself or may be accessible as a web API somewhere on the network or internet. The user or "resource owner" authorizes the client web app to receive that access token by providing credentials to the authorization server. The roles of these components are shown in the diagram below:  

AD FS in Windows Server 2016 [AD FS 2016] enables you to add industry standard OpenID Connect and OAuth 2.0 based authentication and authorization to applications you are developing, and have those applications authenticate users directly against AD FS.+ AD FS 2016 also supports the WS-Federation, WS-Trust, and SAML protocols and profiles we have supported in previous versions. If you are interested in developer guidance for these protocols, see the article here. This article will focus on how to use and benefit from the newer protocol support. Active Directory Federation Services (ADFS) is a software component developed by Microsoft that can be installed on Windows Server operating systems to provide users with single sign-on access to systems and applications located across organizational boundaries.  

Customers utilize Azure AD's Application Proxy for more and more scenarios and applications. So we've made App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups so that you can assign specific connectors to serve specific applications. This capability gives you more control and ways to optimize your Application Proxy deployment. Each Application Proxy connector is assigned to a connector group. All the connectors that belong to the same connector group act as a separate unit for high-availability and load balancing. All connectors belong to a connector group. If you don't create groups, then all your connectors are in a default group. Your admin can create new groups and assign connectors to them in the Azure portal. Default configuration – no use for connector groups If you don’t use connector groups, your configuration would look like this: Recommended configuration – several specific groups and a def...

Connectors can be installed anywhere on the network that allows them to send requests to the Application Proxy service. What's important is that the computer running the connector also has access to your apps. You can install connectors inside of your corporate network or on a virtual machine that runs in the cloud. Connectors can run within a demilitarized zone (DMZ), but it's not necessary because all traffic is outbound so your network stays secure. Connectors only send outbound requests. The outbound traffic is sent to the Application Proxy service and to the published applications. You don't have to open inbound ports because traffic flows both ways once a session is established. You don't have to set up load balancing between the connectors or configure inbound access through your firewalls. For more information about configuring outbound firewall rules, see   Work with existing on-premises proxy servers . Use the   Azure AD Application Proxy Connecto...

Connectors are lightweight agents that sit on-premises and facilitate the outbound connection to the Application Proxy service. Connectors must be installed on a Windows Server that has access to the backend application. You can organize connectors into connector groups, with each group handling traffic to specific applications. Connectors load-balance automatically, and can help to optimize your network structure.

This diagram explains the flow when a user attempts to access an on-prem application that uses IWA. The user enters the URL to access the on-prem application through Application Proxy. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this point, Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication. If the user is validated, Azure AD creates a token and sends it to the user. The user passes the token to Application Proxy. Application Proxy validates the token and retrieves the User Principal Name (UPN) from it, and then sends the request, the UPN, and the Service Principal Name (SPN) to the Connector through a dually authenticated secure channel. The Connector performs Kerberos Constrained Delegation (KCD) negotiation with the on-prem AD, impersonating the user to get a Kerberos token to the application. Active Directory sends the Kerberos token for the application to th...

One your app is published with Application Proxy, you can manage it like any other enterprise app in the Azure portal. You can use Azure Active Directory security features like conditional access and two-step verification, control user permissions, and customize the branding for your app.

With Azure AD Application Proxy you can access different types of internal applications: ·          Web applications that use  Integrated Windows Authentication  for authentication ·          Web applications that use form-based or  header-based  access ·          Web APIs that you want to expose to rich applications on different devices ·          Applications hosted behind a  Remote Desktop Gateway ·          Rich client apps that are integrated with the Active Directory Authentication Library (ADAL)

  Azure AD Application Proxy provides a simple, secure, and cost-effective remote access solution to all your on-premises applications. Azure AD Application Proxy is: Simple You don't need to change or update your applications to work with Application Proxy. Your users get a consistent authentication experience. They can use the MyApps portal to get single sign-on to both SaaS apps in the cloud and your apps on-premises. Secure When you publish your apps using Azure AD Application Proxy, you can take advantage of the rich authorization controls and security analytics in Azure. You get cloud-scale security and Azure security features like conditional access and two-step verification. You don't have to open any inbound connections through your firewall to give your users remote access. Cost-effective Application Proxy works in the cloud, so you can save time and money. On-premises solutions typically require you to set up and maintain DMZs, edge servers, or oth...