DPS907 notes – Tue Dec 6

Modern application architecture and web services.

This page is still being edited. This notice will be removed when the edits are complete.

 

Test today

The weekly test will not be done at the beginning of the class timeslot, due mostly to a delay in getting these notes posted early enough. We will work through some of the content as a group, and have the test later in the timeslot.

 

Theme for today and this final week of the course

You have learned a large number of web services foundational concepts and skills, while writing code for a dozen programming assignments.

Today, we will discuss the role of web services in modern application architecture, for the public web, and for organizations (companies, enterprise, etc.). The goal is to ask you to use what you’ve learned in the future, as you work on systems that could be used anywhere.

We have a test today – the last one of the term – near the end of the timeslot. The last assignment is due tomorrow night. Therefore, attendance in the Thursday class/session is optional. I will be available in case you want to discuss any web services topic. If the classroom is empty, then I will probably be in or near my office.

 

Introduction to modern application architecture

In your academic program’s curriculum plan, there is a third-year “project” course sequence. A small group of students designs and implements a substantial system, during a two-course sequence over an eight-month timeframe. The experience is intended to integrate many/most of the foundation topics covered in the first four or five academic terms.

The project course sequence is often the first opportunity to use a modern application architecture. Web services often (and should!) have an important role in the project, because almost all modern apps are distributed in nature, with parts that run on different kinds of devices.

There are two areas of concern:

  1. Infrastructure
  2. Security

These two areas of concern are overlapping, related, complementary, and interdependent – all at the same time.

 

Overview of the infrastructure concern

The major infrastructure concern is the data store.

In your past experience, you have designed and implemented many kinds of data stores in the apps you wrote for different courses in your academic program. They spanned the range from simple files in the file system, to stores that were managed by a relational database management system.

In this course, you have been exposed to a different way to think about the data store, although it has not been a major focus of our activities. When creating our web services, we realized that it can effectively replace direct access to, for example a database.

Consider a collection of security-aware apps, that are all part of a common pool of apps in an organization. Assume that there is a database server (and the SQL/NoSQL technology implementation is unimportant). Instead of requiring each app in the pool to maintain a technical relationship with the database, we can “convert” database access into a web service.

Then, apps of all kinds – internal-facing and public – can use the web service for data access purposes. The web service will participate in the shared security environment, so that’s not a concern. We know how to create resource representations for internal use, and for public use (by using hypermedia representations).

Here are some resources that will deepen your understanding. Be prepared, they’re long reads.

Software Engineering Stack Exchange – Should you write your back-end as an API?

Software Engineering Stack Exchange – REST API vs directly DB calls in Desktop Application

Stack Overflow – Why should a developer use web services instead of direct connections to a db?

Agile Data essay (Scott Wambler) – Encapsulating Database Access: An Agile ‘Best Practice’

Jeff Atwood (Stack Overflow co-founder), from 2004! – My Database is a Web Service

Search engine words to use: direct database access vs. api

 

Overview of the security concern

In this web services course, recall the sequence in which you learned something about security.

In the early part of the course, we did not use any security features. All resources were open, and all tasks could be done by all requestors.

Then, for an app, we added or configured security. The security system was embedded in the app. If you decided to create a separate but related secured app, it could not use the security configuration that was embedded in the first app.

Finally, we designed and implemented an environment that had a separated and shareable service for identity management and authentication (credential validation).

The result was that you began to learn that security was a feature that could be (must be!) designed in from the beginning, but with care, it could be flexible, with an indication that it could scale.

 

Problems that are beyond the scope of this academic course

In your third-year project course sequence, or later in your first career after graduation, you will soon encounter a set of problems that your security training won’t solve. However, knowing the foundations, you should be equipped to design and implement solutions.

What are the problems in this “security” area of concern?

One is the use of social, or public, login services. Google, Facebook, and Microsoft have web-scale services, widely used, and reasonably popular. We have all used apps (web, mobile device) that had “Login with Facebook” components. How do we handle those?

Another is enterprise login services. Many organizations have and use a directory service, and use it to authenticate its employees/users. Before the web became a viable platform for enterprise apps (whether internal, public, or a mix), enterprise login was simple and easy. Now? Not so much. However, the good news is that the most widely-used enterprise login service – Microsoft Active Directory – is available as an online service, as Azure Active Directory.

The response to the problem in the previous paragraph was federation (which some describe as “single sign-on”). While a solution, it’s a problem too, because of other factors, discussed below.

Application platform diversity – defined as the combination of an operating system, execution environment (runtime), and language services – is a notable problem. The technique that you used to create and use a cluster of Windows OS based ASP.NET web apps and web services works only when all the participating apps are also Windows OS and ASP.NET-based. Add in an app that runs on Node.js on a Linux-based platform, and you can’t just share the familiar-to-you .NET Framework classes that implement security.

Related to platform diversity is device diversity. Before about 2008, we (in the software development world) did not have to be concerned with device diversity. We had servers, and laptops/desktops. That’s all. Now, we have dozens of different kinds of devices, and many/most need security services.

Finally, there’s the problem of scale. How do we think about application architecture in a way that enables the design to survive a small-scale implementation, but allow for the possibility of scale?

We will discuss these problems during our class session, and motivate you to think about solutions you can use now and into the future.

 

The OAuth Authorization Framework

OAuth is an open standard, widely-used on the web for the credential validation part of authentication. It enables developers to outsource all or most of two security tasks:

  1. Identity management
  2. Authentication (credential validation, and therefore cookie/token issuance)

Briefly, OAuth is a framework that enables a client app to use an access token to request a protected resource. The access token is issued to the client app by an authorization server, with the approval of the resource owner.

The ASP.NET Identity system implements the OAuth standards. You will recall seeing pieces of OAuth in the various security components, in apps with security, and in the IA Server app.

The OAuth 2.0 Authorization Framework is described in RFC 6749. A related RFC 6750 covers access token usage.

A gentle overview of OAuth can be found in this Wikipedia article.

Justin Richer and Antonio Sanso have written a book, OAuth 2 In Action. A readable introduction and excerpt is here.

 

OAuth concepts and principles

To get started and learn OAuth, there are four major conceptual areas that you must learn and understand:

  1. Roles (or participants)
  2. Client app type (confidential or public)
  3. Flows that enable a resource owner to authorize the issuance of an access token
  4. Token issuance and format

 

OAuth roles (or participants)

OAuth defines four roles:

 

oauth-resource-ownerResource owner

An entity (e.g. an end user, typically a human person, or a proxy such as credentials in a secure/trusted store) capable of granting access to a protected resource. A resource owner has a user account in the security system’s identity store.

 

oauth-resource-serverResource server

A server that hosts a protected resource. It responds to requests by validating an access token. It trusts the authorization server.

 

oauth-client-appClient

Also known as a client app, this is an application that makes requests for a protected resource, on behalf of the (human) resource owner, and with its authorization. A client app also has an account – similar to a human user account – in the security system’s identity store.

 

oauth-authorization-serverAuthorization server

A server that authenticates resource owners, client apps, and issues access tokens.

 

OAuth does NOT define an identity management role. In other words, it does not concern itself with the design and maintenance of user accounts (whether human or programmatic).

In ASP.NET MVC based web apps and web services, ASP.NET Identity provides identity management services.

For a non-ASP.NET approach, there are many possible solutions; the OpenID Connect initiative, which does handle identity management, is often used with OAuth.

 

Client app type

There are two defined types of client apps:

1. Confidential
Capable of maintaining confidentiality of client app credentials. Includes server-based web apps and services. In summary, the client app has credentials that are used during the token-issuing process. A server-based client app is capable of securely storing its credentials, and not leaking them to the users of the client app.

2. Public
Not capable of maintaining confidentiality of client app credentials. Includes JavaScript apps and modules. Also includes mobile device (e.g. iPhone) apps. In other words, a public client app will not be capable of securely storing its credentials.

 

Flows for token issuance

There are four defined flows or scenarios that enable a resource owner to authorize the issuance of an access token:

1. Authorization code
A resource owner is able to authenticate directly with an authorization server, and passes on an “authorization code” to the client app. Then, the client app uses the authorization code to obtain an access token. This flow features a browser-based redirection component, where the resource owner interacts directly with the authorization server’s authentication UI.

2. Implicit
For client apps which are implemented in a browser using a scripting language (such as JavaScript).

3. Resource owner password credentials
Where there is a high degree of trust between the resource owner and the client app (e.g. the client app is part of the device operating system). The client app presents the authentication UI, but does not save/store the credentials. It simply “exchanges” the credentials for an access token.

4. Client credentials
For access to protected resources that are under the control of the client app (and not to any specific/individual resource owner).

 

Token issuance and format

From the RFC 6749 section 1.4:

Access tokens are credentials used to access protected resources.

An access token is a string representing an authorization issued to the client.

Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.

Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements.

Access token attributes and the methods used to access protected resources are beyond the scope of this specification…

 

The last sentence is meaningful: Please do not assume that the token format that we saw in our ASP.NET Identity apps is the same as the token format that you’ll see with other OAuth systems.

This problem is solved by using an interoperable token format, with software that in effect replaces the generate > encode/encrypt > decode/decrypt process inside an app.

This is what federation does.

 

One OAuth standard that is widely-used is that the tokens are defined to be bearer tokens. In other words, who/whatever holds – bears – the token, is deemed to be an authorized holder – bearer – of the token.

This is similar to your personal experience with a ticket to an entertainment event (e.g. hockey game, live theatre or performance, etc.). You buy a ticket. The ticket gets you into the venue. At the venue door/gate, they don’t go back to Ticketmaster and confirm that you’re the buyer – they just scan/process the ticket, and let you in the door/gate. And, if you cannot attend the event, you can give your ticket to a friend, and the friend will still be able to attend the event, because they hold – bear – the ticket.

Contrast this with an alternative, where the token would be validated with the issuer, each time it’s used. In this scenario, the resource server would contact the authorization server, sending the token, and asking about its validity.

This is similar to your personal experience with a ticket for air travel. You buy a ticket, which includes the requirement to provide passport information. The ticket gets you to the check-in desk at the airport, and then to security, and onto the aircraft. If you decide that you can’t travel, you cannot just give your ticket to a friend. They don’t have your passport and name etc.

 

Our in-class experience with OAuth

First, we must state that the ASP.NET Identity system follows the OAuth standard. Then, depending upon the kind/style of app that we are creating, certain parts of the OAuth standard are implemented. Here are some examples:

Web app only, interactive login

In this style of app, we see very little of OAuth.

The security classes include the ability to handle access tokens, but it’s not used, because interactive browser – web apps use a cookie to store the information normally found in an access token.

Web service, simple app, with embedded security

In this style of app, the resource owner password credentials flow is used.

First, a token endpoint URL is defined (…/token).

Next, the token endpoint collects the credentials (user name and password, with a “grant type” value), and issues an access token as the response.

Subsequent requests must include the access token.

Web service, security-aware, works with an IA Server

In this style of app, we used two different sub-flows.

In the first sub-flow, we used Fiddler as a request-generator. You used the IA Server token endpoint to get an access token. Then, you used that token in requests to the security-aware app.

In the second sub-flow, a third app – a web app with UI – was used to request resources from the security-aware web service. As a trusted web app (because it’s on a server that’s managed by the security environment), it can present UI to gather the resource owner’s credentials, and then request a token from the IA Server. The web app can then store the token in session state.

 

Can we go beyond this? What else is possible?

Yes, we can go beyond this.

We can get social network or enterprise login services involved.

In class, we’ll discuss and diagram the mechanisms.

 

 

( more to come )

 

 

~~~~~~~~~~

More to come…

Study the OAuth framework, and its flows
Social / external / enterprise authentication
Modern application architecture

Gentle intro to OAuth and its flows
Relate it to our context
Recognize its parts in our apps

Social / external / enterprise authentication
How this changes the app design
We still need our own identities, and claims

Modern application architecture
Revisit “client” topic from a few weeks ago
Internal clients, public clients and the need for hypermedia representations

Versioning of the API / web service

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
%d bloggers like this: