Describing .NET My Services

< BACK  NEXT >

[oR]

While they're all part of .NET My Services, it's useful to distinguish between the authentication service and the XML-based services. The information in Passport is not defined using XML, but the access protocol for this service is defined by Kerberos. All data in all other services is represented using XML, and those services are always accessed via SOAP. Accordingly, this section is divided into two parts, one for each of these categories.

.NET My Services includes Passport and a group of XML-based services

Will Users Pay for Services on the Internet?

Up to now, the subscription model hasn't been especially successful on the Internet. Users have resisted paying when so much content is available for free. Yet the kinds of services that can be provided using .NET My Services are quite different from what has gone before. Large numbers of people are clearly willing to subscribe to services that they find valuable, such as cable TV, basic Internet access, and mobile telephony. To make .NET My Services's subscription-based business model work, Microsoft and application developers must provide services that people think are worth subscribing to. Users must be convinced of the value of the services they're getting.

This makes sense new kinds of businesses require providing new value to users and once again, it's a business issue. If Microsoft and independent software developers can't create applications that users are willing to pay for, .NET My Services will die. If they can, however, there's every reason to think that people will pay for user experiences Microsoft's new term for applications that make their lives better.

The Authentication Service: Passport

Controlling which clients are allowed to access data requires knowing that a client is who it claims to be. Accordingly, authentication is at the heart of .NET My Services. Any client that wishes to access any of the .NET My Services relies on Passport to prove its identity. To do this, every .NET My Services user (that is, each principal) is assigned a Passport unique identifier (PUID). PUIDs are unique and unchanging, so once one is as signed, it will always identify the same principal. A PUID can be assigned to a particular person, a group of people, or an application that uses .NET My Services.

Every .NET My Services client authenticates with Passport

In .NET My Services, identity means more than just who a principal is. It's entirely plausible that you might wish to grant or deny access to information stored in .NET My Services based not only on who the principal is, but also on what application the principal is running. To allow this, each request carries the principal's PUID along with an indication of the application this principal is running. This allows things such as granting your broker access to your financial information when he's at the office running an approved application, but not when he's home at night using his own less secure personal computer.

Client identity has two parts

As mentioned earlier, the .NET My Services Passport service relies on Kerberos. This well-understood protocol is also used in Windows 2000 domains and other environments, so it's a familiar solution to this important problem. Figure 8-2 shows a simplified picture of how Kerberos works.^[2] When a user logs in, a request for a ticket-granting ticket (TGT) is sent to the Passport service (step 1). If the user has entered the correct password, the server returns the TGT (step 2), and the login succeeds. (It's important to note that the user's password is not transmitted across the network during this process.) Before the first access to any other service, whether it's one provided by .NET My Services or a service offered by a third-party application, the client presents the TGT to the Passport service and requests a ticket for this new service (step 3). The Passport service uses the TGT to verify the client's identity and, if all is well, returns a ticket to the requested service along with something called a session key (step 4). The client presents this ticket to the service being accessed (step 5), which verifies it, and then decides what access this user is allowed (step 6). The client might be a human being using a desktop computer or PDA, or it might be an application using .NET My Services. Both use tickets to prove their identity, and so both rely on the Passport service.

^[2] This very short description omits many important aspects of the protocol, including how it actually provides its security services. For a more detailed discussion, see Chapter 3 of my earlier book Understanding Microsoft Windows 2000 Distributed Services (Microsoft Press, 2000).

Figure 8-2. Kerberos uses tickets for authentication.

As used by .NET My Services, Passport relies on Kerberos

Along with authentication, Kerberos also provides data integrity and data privacy. To achieve these things, the session key returned in step 4 is used to encrypt information sent between the client and the software the client is accessing. When a client accesses .NET My Services, all user data sent on the request is encrypted with this key.

All .NET My Services user data is encrypted when sent across the network

XML-Based Services

With the exception of Passport, application developers see every service provided by .NET My Services as a collection of XML documents. Each service has an XML schema that describes the types of information it can contain. For example, the schema for the .NET Calendar service defines types such as event and reminder, while the schema for the .NET Profile service defines the type's name, address, emailAddress, telephoneNumber, picture, and more. Schemas can also contain an any block, allowing an application to insert arbitrary information into a user's entry.

Each XML-based service provided by .NET My Services has its own schema

Single Sign-on for the Internet

Users hate having multiple passwords. Single sign-on, the ability to log on once with one password and then access any number of systems on the Internet, could solve this problem. Making users' lives simpler in this way is a primary goal of Passport.

Yet single sign-on for the Internet also raises troubling questions. If only Microsoft provides the service, won't the company gain enormous control over what should be a multivendor network? One roadblock to this potential single-vendor dominance is that competitors are likely to appear, providing choices for both applications and end users about which authentication service they use. Another mitigating factor was mentioned earlier: Microsoft will allow federation of the .NET My Services Passport service. Using Kerberos, other organizations will be able to authenticate users without Microsoft's direct involvement. People who don't trust Microsoft to perform this function can turn to another authentication provider in the Passport federation.

While this dispersal of control might make customers feel more comfortable, it has the potential actually to make them less secure. In a federated Passport scheme, for instance, each Kerberos implementation needs to trust all of the others to authenticate users correctly. Is it safer to trust just one organization to do this correctly, or would you prefer to trust a potentially large group of organizations? Microsoft has talked about ranking different Kerberos providers in the federation according to how trustable they are, which might help. In any case, there are tradeoffs between security and control.

Even if no single vendor has total control, single sign-on for the Internet brings other concerns. For example, if I can log on just once to access many systems, doesn't this make the potential damage a successful attacker can do that much greater? If that attacker can somehow learn my password, he can now masquerade as me on many different sites.

Single sign-on is probably a mixed blessing. Some form of it is slowly working its way into the Internet, and .NET My Services looks likely to accelerate its growth. Like so many things, however, this rose is not without thorns.

Storing Data

To understand what .NET My Services provides, it's useful to have a simple mental model of how the data it stores is organized. Conceptually, all of the XML-based services are implemented as data stored in some kind of database. To improve reliability and availability, the information in these services is replicated and stored at various .NET My Services data centers. The .NET My Services database is also partitioned, so the information in one user's .NET Calendar service might be stored in different physical locations than the information in another user's .NET Calendar service. This distribution isn't visible to applications, however it's hidden by the .NET My Services infrastructure.

Data stored in .NET My Services is replicated

Each XML-based service is identified with a uniform resource identifier (URI). For example, the .NET Profile service might be named with the URI http://profile.microsoft.com/net. To access a service, an application specifies that service's name and then works with .NET My Services to locate the appropriate server. Along with naming a service, an application using an XML-based service must also specify which instance of the service it would like to access. In other words, the application must identify a particular user whose data it's interested in. To do this, the application supplies the PUID of the target user. As Figure 8-3 shows, .NET My Services can be thought of conceptually as a database of XML documents, organized by service, with PUIDs acting as the key for each. As the figure suggests, not all users will subscribe to all services, so each service has a document associated with a PUID only for its subscribers.

Figure 8-3. Each service can be viewed as a collection of XML documents indexed by PUIDs.

A client uses a PUID to identify an instance of the service it wishes to access

Accessing Data

Each XML-based service that .NET My Services provides is accessed through an XML Message Interface (XMI). .NET My Services is a new kind of application platform, one that exposes XMIs rather than conventional application programming interfaces (APIs). A .NET My Services application accesses the platform's services via these XMIs much as a conventional application accesses operating system services via APIs. Each XMI defines a set of XML messages that can be sent to and received from a particular service. And no matter what those messages are or what a service does, applications using any XML-based service always access it through SOAP.

The information in .NET My Services is accessed through XMIs

Each XML service exposes a common set of standard methods that include query, insert, delete, and update. Each of these methods does just what its name suggests to the data that service maintains. While the names of these methods are common across all of the services, the information sent as parameters and results is service-specific. Along with these standard methods, each service can also expose custom methods. For example, the .NET Inbox service provides the additional methods sendMessage, saveMessage, and copyMessage. The goal is to let each service expose common functions in a common way while still leaving the service's designer free to provide whatever is needed to meet that service's goals.

The XML-based services each expose a group of methods

The Risk of Committing to .NET My Services

Developers who create applications that depend on .NET My Services might feel that they're at Microsoft's mercy. Once they've committed to the platform, Microsoft could raise the price it charges for these services at any time. Microsoft is not a charity, so what stops the company from instituting outrageous fees for developers who can't easily move their applications elsewhere?

Well, what stops any vendor from raising its prices at will? The answer is simple: competitors. If this emerging market behaves like other markets, competition will keep Microsoft from being able to raise prices once developers become dependent on .NET My Services. If no competitors emerge, then it's likely .NET My Services itself won't be a success, since good ideas always attract others to a market. I'd also expect to see the creators of applications built on .NET My Services demand long-term contracts that lock in reasonable prices.

Microsoft certainly does have one big advantage over any potential competitors, however: It can bundle .NET My Services into Windows. Extending its reach from the desktop to the Internet is no doubt attractive to Microsoft (and to its shareholders). This idea is surely much less attractive to Microsoft's competitors, however. Whatever happens, don't expect this battle over Internet-based Web services to end anytime soon. Microsoft, and probably some of its competitors as well, looks to be in it for the long haul.

Each request identifies a service, a target PUID, who the client is, and more

As Figure 8-4 illustrates, an application accessing .NET My Services data creates a SOAP request containing various pieces of information. Among other things, that information includes the name of the target service (such as .NET Contacts), the PUID of the user whose service instance should be accessed, the client's Kerberos ticket (which contains the client's PUID and other information), and a call to a method provided by that service. Each query is an XPath expression, and any results are returned as XML-defined data.

Figure 8-4. A client accesses .NET My Services via SOAP, with each request carrying a specific set of information.

.NET My Services uses several custom SOAP headers

As described in Chapter 2, SOAP itself is specified using XML, and it defines an envelope containing a body with an optional header. The body contains the parameters or results of a particular call, while the header can contain a variety of things. .NET My Services uses several headers that convey specific information about a particular call. The headers it uses are effectively those defined by Microsoft's Global XML Web Services Architecture (GXA). As described in Chapter 2, these headers provide a standard mechanism for conveying authorization information such as a Kerberos ticket, for relaying messages, and for carrying out other useful functions. Clients can access .NET My Services using either SOAP over HTTP, likely to be the most common approach, or the direct SOAP- to-TCP mapping called Direct Internet Message Encapsulation (DIME).

.NET My Services uses roles and ACLs to provide access control

Controlling Access to Data

To fulfill its promise, .NET My Services will need to provide users with a very high level of control over how their data is made available. In .NET My Services, authorization determining which clients can access which data is based on the notion of roles. Each client can be assigned to a particular role, and a service's owner can use access control lists (ACLs) to determine which roles have which access rights. Different services can have different allowable roles, each allowing a particular kind of access and view of the data that service provides.

Each service defines an appropriate group of roles

For example, the .NET Calendar service includes (among others) roles with the following abilities:

• Full access to all the information stored by a particular instance of this service. You would typically be in a role with this ability when accessing your own calendar.

• Access to only public data in the service. For example, an executive assistant may be able to manage work-related information in your calendar while having no access to your personal entries.

• Read-only access to the service's data. Your spouse might have this ability, allowing him or her to see what your plans are.

Other services have other roles, each providing a style of access appropriate for the various users that service is likely to have.

< BACK  NEXT >