Monthly Archives: January 2009

The case of the missing binding

Leave a reply

Today, while preparing a training session on WCF, I decided to use Eclipse’s Web Services Explorer (WSE) to view and interact with a WCF-based service (using plain WSHttpBinding).

However, after processing the service’s WSDL description, WSE showed a service with an empty binding list.

Knowing that some web services stacks don’t support WSDL descriptions divided into multiple files, I used the FlatWSDL endpoint behavior authored by C. Weyer. This behavior extends WCF’s WSDL exporting mechanism, by inlining in the WSDL document all the schemas directly or indirectly referenced by it.

Unfortunately, the behavior of WSE remained the same: it continued to show a service with no bindings. After inspecting again the generated WSDL, I observed that it was still divided into two WSDL documents: the first one with the <service> and <binding> elements, and the second one (imported by the first) with the remaining WSDL elements and the flattened schemas.

The reason for this division is explained in this post by Kirill Gavrylyuk: this division is used when there are WSDL elements (<service>, <binding>, <portType>, …) in different namespaces.

So, a solution is to put all the elements in the same namespace, which also is described in the same post.

After this change, all the WSDL elements were contained in a single document and WSE finally showed the service binding.

These are the joys of interoperability.

A References List for SOAP based Services Security

Leave a reply

For more that one time, I’ve been asked for a list of references regarding security in SOAP-based services. This time, I’ve decided to blog it so that I can find it/link to it in the future: 

 

  • The Laws of Identity
    Introduces the concepts of an identity meta-system and of claims-based digital identities.
    Also contains a set of laws, describing requirements that an digital identity system should possess.
  • Design Rationale behind the Identity Metasystem Architecture
    Describes the identity meta-system architectural elements, the rational behind them, and how they can be mapped to concrete technologies and specifications.

 

 

  • WS-Trust 1.3
    Introduces the concept of Security Token Services (STS) as a service for the issuance of security tokens. It also defines a request-response protocol for interacting with the STS.
    An STS concretizes the claims transformer abstract concept, which is a key element in the identity meta-system.
    This specification builds upon the WS-Security specification.

 

  • WS-SecureConversation 1.3
    Defines how to optimize conversations comprised by more that one message interaction, by defining the concept of a security context and a security context token that refers to it.
    This specification builds upon the WS-Security and WS-Trust specifications.

 

 

  • Web Services Policy 1.5
    Defines a model and associated XML syntax for describing service’s requirements and capabilities. It is based on the abstract concept of policy assertion, which defines one requirement or capability.

 

  • WS-SecurityPolicy 1.2
    This specification defines several concrete policy assertions for the security domain.

 

Using Digital Credentials on The World-Wide Web

Leave a reply

While looking for references on Automated Trust Negotiation, I found this paper: M. Winslett, N. Ching, V. Jones, I. Slepchin, “Using digital credentials on the World Wide Web”, Journal of Computer Security, 1997.

The concepts and solutions proposed by this paper, more than ten years ago, have lots of similarities with more recent proposals, such as the Identity Metasystem and related specifications.

1. Access control based on properties of the requestor

“…we have been investigating the use of digital credentials, which may be thought of as on-line analogues to the paper credentials that people carry in their wallets. (…). These credentials can be issued (typically online) by the same kinds of authorities as issue paper credentials today: voter registrars, driver’s license facilities, schools, employers, hospitals, etc. The credentials can be submitted along with a request for service to prove that the client has the particular properties required by the service provider of its clients. Using modern encryption technology, digital credentials can be made unforgeable and verifiable

Winslett et. al propose this credential-based approach in opposition to the classical identity-based approach

“Traditionally, it has been thought that authentication facilities provide the answer to this problem. Authentication allows a service to verify the identity of a client,(…). But knowing the identity of a client is not enough to ensure that the client is over 21 or does not live in Texas – in fact, the client’s exact identity is irrelevant in these cases, and the client might be reluctant to divulge its identity for privacy reasons.

The Identity Metasystem extends the definition of identity to incorporate these properties, renamed as claims:

“In the Metasystem, digital identities consist of sets of claims made about the subject of the identity, where “claims” are pieces of information about the subject that the issuer asserts are valid. This parallels identities used in the real world. For example, the claims on a driver’s license might include the issuing state, the driver’s license number, name, address, sex, birth date, organ donor status, signature, and photograph, the types of vehicles the subject is eligible to drive, and restrictions on driving rights

In the proposal by Winslett et al., properties are transported inside unforgeable and verifiable credentials, such as X.509 certificates. In the Identity Metasystem, this role is played by security tokens, such as SAML assertions, which can be signed (unforgeable) and have cryptographic subject confirmation methods (verifiable).

2. Policies describing credentials requirements

In Winslett et. al.:

The applications running at Web servers (…) must have policies on which credentials are required for which services. (…) In addition, servers must have a means of communicating their policies to clients, so that clients can obtain and attach appropriate credentials to requests.

In the Identity Metasystem:

Format and claims negotiations between participants are conducted using WS-MetadataExchange (…) and WS-SecurityPolicy (…)

3. Client side security agent

In Winslett et. al.:

The central task of the personal security assistant (PSA) is to manage a client’s credentials in accordance with the stated policies of the client. The PSA helps the client obtain credentials, stores them locally, attaches them to service requests in accordance with the policies established by the client, determines what credentials are needed for a particular service request, and communicates as needed with the client while carrying out its assigned tasks.

In the Identity Metasystem, this role is played by the Identity Selector

The Identity Metasystem employs software on each platform that lets users choose an identity from among their portfolio of identities to use for each authentication. This software is called the Identity Selector, and is invoked each time the user needs to make a choice of identities.