Browse Prior Art Database

Wide-Area Dynamic Attributes Exchange

IP.com Disclosure Number: IPCOM000201716D
Publication Date: 2010-Nov-19
Document File: 2 page(s) / 63K

Publishing Venue

The IP.com Prior Art Database

Abstract

These days, many systems are connected each other and exchanges users' attributes to improve the services or impose users access control along with the information. However, most current protocols for single sign-on only provide a function to exchange users' attributes between an authentication server and a service server. It means when we want to exchange attributes between servers that provide services, we cannot realize it with existing protocols. This idea realize an attributes exchange function between not only an authentication server and a service server but also such service servers safely even if it will be implemented in existing protocols.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

Wide-Area Dynamic Attributes Exchange

Other protocols, like SAML and OpenID, already provide an mechanism for attributes exchange, but these mechanisms have some considerations.
1: The exchangeable attributes are only the attributes in the user registry of authentication server .
2: Because they use only a timestamp as a security related value in attribute exchange messages , it is vulnerable to replay attacks.
3: Before attributes are exchanged, they have to adjust the attributes names between services in case they use different names in the system.

This idea provides 3 mechanisms below for hem.
1: Allowing the attributes in the user registries of service serves to be exchangeable
2: Preventing replay attacks by inserting nonce data in the attribute exchange messages and validating the values
3: Allowing end users to map their attributes among services so that the attribute names adjustment is not needed before the attributes exchange

In this idea, we don't define the authentication mechanisms.

We assume that this idea will be used in other authentication mechanisms, like SAML and OpenID, to add flexible attributes exchange functions.

We describe the main behavior this mechanism with a protocol flow below.

In this flow, we focus on only an attributes exchange between service servers, however; when we think of the attributes exchange between an authentication server and a service server, there is no big differences because some messages are just omitted in such a case.

*Premise


A client user uses two web services (service A and B) with a web browser.

The user is already authenticated by an authenticate server for these services.

We will explain how the attributes in the service B is sent to the service A which the user is using.

*Message flow

1: The client user requests the attributes in the service B to the service A. (for example, the user asks the service A to use the email address in the service B)
2: The service A makes a redirect message (browser post redirect message) towards the service B, and sends it to the user.
3: The message is automatically sent from the end user to the service B.
4: An authentication process happens if the user is not authenticated in the service B. (If already authenticated, this step is skipped)
5: The service B receives the message and return an exchangeable attributes list.
6: The user requests som...