Enabling Attribute Delegation in Ubiquitous Environments

Isaac Agudo, Javier Lopez, Jose A. MontenegroComputer Science Department, University of Malaga, Spain

{isaac,jlm,monte}@lcc.uma.es

Abstract

When delegation is implemented using the attributecertificates in a Privilege Management Infrastructure(PMI) [2, 11, 4], it is possible to reach a considerablelevel of distributed functionality. However, the ap-proach is not flexible enough for the requirements ofubiquitous environments. The PMI can become a toocomplex solution for devices such as smartphones andPDAs, where resources are limited. In this work, wesolve the previous limitations by defining a secondclass of attributes, called domain attributes, whichare managed directly by users and are not right un-der the scope of the PMI, thus providing a light so-lution for constrained devices. The two classes ofattributes are related by defining a simple ontology.While domain attribute credentials are defined usingSAML notation, global attributes are defined usingX.509 certificates. For this reason, we additionallyintroduce XSAML so that both kinds of credentialsare integrated. We also introduce the concept of At-tribute Federation which is responsible for supportingdomain attributes and the corresponding ontology.

1 Introduction

Much has been written about identity manage-ment [12] and federation. We believe this is an ev-idence of the need for a distributed solution in re-sponse to those issues. When dealing with distributedsolutions in the Internet, one realizes about the dif-ficulties to build an infrastructure from scratch. Infact, organizations tend to reuse existing solutionsand define interconnection mechanisms to allow in-

teroperability. This problem has been approachedusing different mechanisms, but we are particularlyinterested in federations.

In federations, several service providers delegatethe identity management to a third party who is re-sponsible of collecting identity information and au-thenticating users. In this way, service providers relyon the third party to authenticate users and decide,according to the identity of the user, whether the re-quested service can be provided.

One interesting problem here is that serviceproviders, even if they do not have to perform userauthentication, need at least to know the potentialusers. In the case where the potential users are un-known, access control policies of unknown users needto be defined, what implies relying on the third partyalso during the access control phase. Hence, there isa distinction between already known users and thosenot yet known, which makes the definition of accesscontrol and authorization policies harder.

Even if the service provider knows all the users, itmay be more difficult to rely on identities for the defi-nition of authorization policies than to use attributesfor this purpose. Moreover, by using attributes, theuse of identities can be avoided entirely in the defini-tion of authorization policies. This is why we shouldconsider an analogous concept to Identity Federation,but using attributes instead of identities for the def-inition of the authorization rules. In this way, userswill not carry out the trust negotiation by themselvesbut they will request the federation to do it.

In [7, 14, 8, 6, 15] the concepts of automatedtrust negotiation (ATN) and the concept of At-tribute Based Access Control (ABAC) are introduced.ABAC is an access control model which defines au-

1

thorization policies based on user’s attributes. Whenusing this approach, attributes such as financial ormedical data may be sensitive. The ATN implementsthe mechanisms which avoid disclosure of confidentialattributes.

The main contribution of our work is the possibilityof moving the ATN from the user side to the attributeFederation side. Thus, in our scenario, users do nothave to worry about disclosure of sensitive data, they“instruct” the federation on how to handle the pro-cedure, and allow it negotiate on their behalf. As aresult, neither requesters nor service providers haveto be involved in the trust negotiation phase beforebeing able to establish a session.

It is important to note that, in ubiquitous envi-ronments trust relations are more important than incentralized scenarios and are the foundation for thedecision making process in most cases. Also, iden-tities are rarely used due to the dynamic character-istics of those environments. Besides that, the at-tribute federation becomes more important for ubiq-uitous devices as they do not usually know their po-tential neighbors before they enter the device net-work. Moreover, the more processes we outsource,the less resources are needed in devices using this at-tribute federation for defining the authorization poli-cies, what is important because when we focus on mo-bile devices, such as PDAs or cellular phones, savingresources is one of the first priorities. This is anotherreason why in these kinds of devices the concept ofattribute federation becomes attractive.

According to this argumentation, the paper outlineis as follows. In section 2, related work is presentedfrom both the theoretical and more practical point ofview. Section 3 introduces XSAML as mechanism tointerconnect SAML and X.509. In section 4 we intro-duce the concept of attribute federation and justifyits need. Section 5 details some implementation is-sues and, finally, section 6 provides some conclusions.

2 Related Work

In this section we review some proposals related withthe idea of attribute federation. We have focused onone academical research result and on one applied

solution.

2.1 RT Framework.

Li et al. proposed logic programming as a way tomodel authorization and delegation relations [9]. Al-though they use Roles for this purpose, their roles canalso be interpreted as attributes, as it is commentedin their work. They define a full general framework,RT for Role Based Trust Management. It comprisedof five different solutions, each of them with differentcharacteristics. Roles can be interpreted as privilegesor attributes. The RT Framework defines a partialorder in roles, establishing how rights can be inher-ited.

RT defines several types of credentials, the basicones are:

1. A.R← D: This credential can be read as D hasthe attribute A.R, or equivalently, A says that Dhas the attribute R.

2. A.R ← B.R1: This credential can be read as ifB says that an entity has the attribute R1, thenA says that it has the attribute R.

3. A.R← A.R1.R2: This credential can be read asif A says that an entity B has the attribute R1,and B says that an entity D has the attributeR2, then A says that D has the attribute R.

4. A.R ← B1.R1 ∩ B2.R2 ∩ . . . ∩ Bn.Rn: This cre-dential can be read as A believes that anyone whohas all the attributes B1.R1, . . ., Bk.Rk also hasthe attribute R.

RT defines an attribute federation using linkedroles. In this way, users can link their attributesto other users’ attributes, defining then their autho-rization policies in terms of other users attributes.However, it is not clear how and where credentialsand authorization policies are stored or who definesthem.

In the example 2.1 there is a federation betweenEOrg.preferred and IEEE.member, so EOrg del-egates to IEEE when making a decision on thepreferred attribute. This is done by defining a

2

EPub.disct ←EPub.preferred∩EPub.studentEPub.preferred ← EOrg.preferredEOrg.preferred ← IEEE.memberEPub.student ← EPub.university.stuIDEPub.university ← ABU.accreditedABU.accredited ← StateUStateU.stuID ← AliceIEEE.member ← Alice

Figure 1: RT Federation example

local map in the domain of EOrg from attributeIEEE.member to attribute preferred. Therefore,EOrg trusts IEEE issuing the attribute IEEE.member,and it knows, to some extent, the reasons and im-plications of the issuance of this attribute. Beforedefinition and federation of an attribute, the definingentity must collect all the information related to theother attribute in the federation.

2.2 SAML

SAML, developed by the Security Services TechnicalCommittee of OASIS, is an XML-based frameworkfor communicating user authentication, entitlement,and attribute information. It is used in many secu-rity applications. In particular, the Shibboleth [18]software implements the OASIS SAML v1.1 specifi-cation [16], providing a federated Single-SignOn andattribute exchange framework. Liberty Alliance [1] isalso a federation solution based on SAML.

Version 2 of SAML presents in its TechnicalOverview ([17]), presents an Attribute Federationscenario. They conceive attribute federation as a wayof passing attributes from one domain to another.In this way, service providers may pass requests toother service providers with attached attributes. Thefollowing Attribute Federation scenario is extractedfrom [17].

1. The user is challenged to supply their credentialsto the site AirlineInc.com.

2. The user successfully provides their creden-tials and has a security context with the Air-

lineInc.com identity provider, the user namedsupplied is John.

3. The user selects a menu option (or function) onthe AirlineInc.com application what means thatthe user wants to access a resource or applicationonCarRentalInc.com.

4. The AirlineInc.com service provider sends aHTML form back to the browser. The HTMLFORM contains a SAML response, within whichthere is a SAML assertion about user John. Thename identifier used in the assertion is an ar-bitrary value (“wxyz”). The attributes “goldmember” and a membership number attribute(“1357”) are provided. The name John is notcontained anywhere in the assertion.

5. The browser, either due to a user action or viaa “-submit”, issues an HTTP POST containingthe SAML response to be sent to theCarRentalInc.com Service provider.

6. The CarRentalInc.com service provider’s Asser-tion Consumer service validates the digital sig-nature on the SAML Response. If this and theassertion are correctly validated, a local sessionis created for user John. This is determined froma combination of the gold member and member-ship number attributes. It then sends an HTTPredirect to the browser causing it to access theTARGET resource, with a cookie that identifiesthe local session. An access check is then per-formed to establish whether the user John hasthe correct authorization to access theCarRentalInc.com web site and the TARGET re-source. If the access check is passed, the TAR-GET resource is then returned to the browser.

In this scenario, the attribute “gold member” anda membership number attribute are passed to the ex-ternal service provider along with the request. Thisproposal focuses on including attributes in the singlesign on process, but not on how relationships betweenattributes are established. Moreover, although at-tributes are passed to the final service provider from

3

Browser

Service Provider (Airlinellnc.com)

Resource

Assertion Consumer

ServiceAccessCheck

IdentityStore

Service Provider (CarRentallnc.com)

IdentityStore

Attribute based

accountAttributes Identity

Credential Challenge

User Login

Select Remote

Resource

Response in HMTL

FormPOST

<Response>

AccessResource

Resource

12

3

4

5

6

7

Identity Provider (Airlinellnc.com)

Figure 2: SAML attribute federation scenario

the initial one, in the end it has to recover the identityof the requester in order to be able to check the re-quest. Thus, access control is not based on attributesbut on identity; attributes are used only as a meansof transporting the identity.

This protocol supposes that the requester firstsigns on some domain prior to accessing the real ser-vice provider. In a real attribute federation, the finalservice provider does not have to be known by theinitial service provider. It means that if CarRental-Inc.com trusts the attribute gold member, it does nothave to let AirLineInc.com know. Only the car rentalcompany is involved and the airline company does notneed to be informed. The process of establishing theattribute federation is carried out by the entity whotrusts and should be autonomous from the trustedentity.

3 XSAML

Our initial purpose when designing XSAML was totranslate the information stored in attribute certifi-cates to SAML code and vice versa. XSAML has anoutstanding role in our scheme, bridging the gap be-tween the Global Attributes and Domain Attributes.The Global attributes are defined using X.509 at-tribute certificates whereas the Domain attributes aredefined using SAML. Therefore, XSAML symbolizethe glue in our infrastructure because makes possiblethe translation process between Global and DomainAttributes.

As aforementioned, SAML is defined using XML[10] sentences whereas X509 attribute certificates aredefined using ASN.1 [3]. A performance comparisonbetween both technologies was presented in [5], show-ing that ASN.1 encode, decode and file space is moreeffective than XML and, therefore, SAML. On theother hand, XML technologies are nowadays morewidespread than products based on ASN.1. For thisreason, we establish a mixed system using SAML and

4

attribute certificates technologies.The structure of X.509 attribute certificate and a

brief example of its corresponding ASN1 encoding isshown in figure 3 (for detailed information see [13]).

AttributeCertificate ::= SEQUENCE { acinfo AttributeCertificateInfo, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }

AA signature

Extensions

Iss. Unique Identifier

Holder

Validity period

Issuer

Signature Algorithm

Serial Number

Version

Attributes

Figure 3: X509 Attribute Certificate and ASN1 rep-resentation

Additionally, an example of SAML sentences isshown in figure 4. Furthermore, the relationship be-tween SAML and X509 attribute certificate fields isdescribed in the table 1.

<saml:Assertion …>

<saml:Conditions …/>

<saml:AttributeStatement>

<saml:Subject>

<saml:NameIdentifier SecurityDomain=“snakeoil.edu”

Name=“Subject1” /> </saml:Subject>

<saml:Attribute AttributeName=“Pass_Test1_Subject1”

AttributeNamespace=“http://snakeoil.edu”>

<saml:AttributeValue> Pass_Test1_Subject /saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

Figure 4: SAML example

3.1 Overview of XSAML

Figure 5 shows a brief description of XSAML system.The main design goal has been to facilitate suitability

SAML Assertion Attribute CertificateIssuer Issuer of AttributeSubject of the Query Certificate SubjectValidity period AC Validity periodAttributes AC Attributes

Table 1: Relationship between SAML and AC fields

to any environment. In this way, when a task dependson the environment, an interface will be created andprogrammers will be able to add code according tothe requirements of the environment in question.

RequestReceiver (SOAP/HTTP) RequestHandler

Configuration File

Attribute

Certificates

Translator

…

Request

Response

Interface 1

ENTRY MODULE

Authorization

Validation

JAVA INTERFACES

KeyStore

Figure 5: XSAML components

The main components of the proposal are:

• Entry Module holds a servlet, named Re-questReceiver. This class is implemented toexchange messages with the Service Provider(client) using SOAP over HTTP. Programmerscan implement other classes to achieve thesetasks. When the RequestHandler processes therequest, it sends a response to the Entry Module(in this case RequestReceiver or another classdesigned).

• RequestHandler is the main class for process-ing the request. It allows programmers to createnew classes in the Entry Module; in other words,new ways to exchange messages with the ServiceProvider.

5

• Finally, we describe the java interfaces. Theymake the system configurable. These interfacesare used to authorize the requester (interface Au-thorization), validate requester’s certificates (in-terface validation), and access the attribute cer-tificates (interface AttrCertHandler).

3.2 Integrating XSAML in a system

XSAML must be integrated into a system with spe-cific features. In the above sections we describe howto achieve the full and partial integration of XSAMLin a target system.

3.2.1 Full Integration

Figure 6 details the full integration, where XSAML isintegrated fully inside the system. XSAML receivesSAML Requests from clients. Then, it processes therequest exchanging information through the systeminterfaces. When the response is made, XSAML is-sues the SAML Response to the client.

As the RequestSender (client) is out of the focus ofXSAML, it must be improved before being used. Infull integration, programmers only have to implementthe interfaces to integrate XSAML. SOAP protocolover HTTP is the communication protocol used toexchange data between XSAML and the clients.

Client translator Inter faces

SYSTEM

Request

Response

Data Exchange

XSAML

SYSTEM

Figure 6: XSAML Full integration

3.2.2 Partial Integration

This scenario shows (figure 7) partial integration.Entry Module classes are not integrated into the sys-tem and therefore data exchanging is managed bythe system. The system must issue a SAML Requestto XSAML and it must process the request throughthe system interfaces. Finally, the translator XSAMLsends a SAMLResponse to the System.

translator Inter faces

SYSTEM

Client

XSAML

SYSTEM

SAML Request

SAML Response

Figure 7: XSAML Partial integration

3.3 Functional Scenarios

Several scenarios can be established by using XSAMLtechnology. In this section, we will show three possi-ble scenarios.

• Scenario A: In this scenario, the ServiceProvider (SP) sends a request with the subject,name and namespace of the attributes (1). TheIdentity Provider (IdP) issues a request (via At-trCertHandler) to the LDAP server or any at-tribute certificates repository, specifying the sub-ject, name and namespace of the attributes (2).

When the AttrCertHandler receives the re-quested attribute certificates, it sends them tothe Identity Provider attached to a namespace(3). Finally, the Identity Provider sends a re-sponse to the Service Provider, containing thesubject, name, namespace and value of the at-tributes (4).

6

SP IdP Attribute Certificates

Subject Attr. Name 1 Attr. Namespace 1 Attr. Name 2 …

Subject Attr. Name 1 Attr. Namespace 1 Attr. Name 2 …

Attr.Certificate 1 Namespace 1 Attr.Certificate 2 …

Subject Attr. Name 1 Attr. Namespace 1 Attr. Value 1 Attr. Name 2 …

1 2

4 3

Figure 8: Scenario A

• Scenario B: In this scenario, the Serviceprovider sends a request with the subject andthe attribute name (1). The Identity Providerissues a request (via AttrCertHandler) to theLDAP server or any attribute certificates repos-itory, specifying the subject and the attributename. (2).

When the AttrCertHandler receives the re-quested Attribute Certificates, it sends them tothe Identity Provider attached to a namespace(3). Finally, the Identity Provider sends a re-sponse to the Service Provider, containing thesubject, name, namespace and values of the at-tributes (4).

• Scenario C: The Service Provider sends a re-quest with the subject and the attribute name(1). The Identity Provider issues a request (viaAttrCertHandler) to the LDAP server specifyingthe subject and the name of the attributes (2).

When the class AttrCertHandler receives the re-quested Attribute Certificates, it sends them tothe Identity Provider (3). Finally, the IdentityProvider sends a response to Service Provider,containing the subject, name and values of theattributes (4).

SP IdP Attribute Certificates

Subject Attr. Name 1 Attr. Name 2 …

Subject Attr. Name 1 Attr. Name 2 …

Attr.Certificate 1 Namespace 1 Attr.Certificate 2 …

Subject Attr. Name 1 Attr. Namespace 1 Attr. Value 1 Attr. Name 2 …

1 2

4 3

Figure 9: Scenario B

SP IdP Attribute Certificates

Subject Attr. Name 1 Attr. Name 2 …

Subject Attr. Name 1 Attr. Name 2 …

Attr.Certificate 1 Attr.Certificate 2 …

Subject Attr. Name 1 Attr. Value 1 Attr. Name 2 …

1 2

4 3

Figure 10: Scenario C

4 Attribute Federation

In this section, a new concept is introduced, AttributeFederation (AF). AF is required when several ubiqui-tous service providers share a common context. Theconcept introduced is explained using the followingscenario.

Let us suppose a University in which Users are ei-ther Professors or Students and in which their de-vices may act as service providers, e.g. providingclass notes, maybe performed either by Studentsor by Professors. In this case, the University de-fines some generic attributes with or without pa-rameters, e.g. Student, Enrolled(Subject), Professor,

7

Teach(Subject) and so on, that help characterizingentities at the University.

These types of attributes are named as Global At-tributes and are defined and issued by Attribute Au-thorities. The Attribute Authority (AA) could bepart of an existing infrastructure such as for instancean X.509 (PMI) [13]. The definition of this type ofAttribute must be reduced because in ubiquitous sce-narios the global infrastructure should only be usedin specific situations. The university is in charge ofdefining and issuing those attributes to Students andProfessors, therefore each university acts as an AAinside the PMI.

Once those basic attributes have been issued,some Professors may need to define new attributessuch as,Pass Test1 Subject1 or Pass Global Subject1.These specific attributes can be used to control stu-dent progress, access to money grants, awards, accessto other subjects, etc. These attributes are namedas Domain Attributes. The Domain Attributes aredefined locally and its meaning is limited to thedomain in which they were defined. These type ofattributes make the system more dynamic becausethey do not require the same verification process ofGlobal Attributes, which could be a very expensiveprocess.

In some cases, there are relationships betweenattributes, i.e. Pass Global Subject1 may implyPass Test1 Subject1 in the case where passing thefirst test is a requirement for passing the subject.Then, along with the attributes, there is a partialorder that defines a simple ontology [19] in the do-main of the attribute manager. An ontology is a datamodel that represents a set of concepts within a do-main and the relationships between those concepts.It is used to reason about the objects within thatdomain. This ontology encodes the relationships be-tween the attributes in the system. Moreover, theremay be relationships between attributes in differentdomains, e.g. different Professors may issue differ-ent attributes. In order to make a reference to theattribute domain we use the dot notation. For in-stance, Prof1.Pass Test1 Subject1 is an attributecreated by Professor1 and managed by him whichstates that the first test of Subject1 has been passed.

This attribute on its own has only a local meaning inthe domain of Professor1.

In the University scenario, the University must pro-vide a server to store the particular attributes definedby its members and also the relationships betweenthem.

As it occurs in many Universities, some subjectsmay share some topics. Let us suppose for examplethat the first part of subject1 is equivalent to the sec-ond part of Subject2. In this case, the professor ofsubject2 (Professor2) may rely on the previously de-fined attributes and define an attribute relationshipstating that the first test of subject1 implies passingthe second test of subject2. In this way, Professor2gives the previous attributes defined by professor1 anew meaning outside its context, by uploading thefollowing relation to the university server:

Prof1.Pass Part1 Subject1→ Prof2.Pass Part2 Subject2

This can be also represented using the partial ordersymbol,

Prof2.Pass Part2 Subject2 ≤ Prof1.Pass Part1 Subject1

In this case, Professor2 is delegating his authoriza-tion on passing the second part to Professor1. Then,a student who is trying to convince the Universitythat he has passed the second test of subject2 mayshow his identity details to the University so it couldask professor2, or may show professor1’s attributestating that he has passed the first test of subject1together with the attribute relationship

Prof2.Pass Part2 Subject2 ≤ Prof1.Pass Part1 Subject1

signed by professor2. So, the process can be carriedout without involving Professor2.

Although Domain and Global attributes are dif-ferent concepts, they can also be related using apartial order. An AA may decide to transform aDomain attribute into a Global attribute by defin-ing an order relation of the form AA.Global1 ≤Entity1.Attribute1. In this way, an AA can del-egate some attributes to other entities in the fed-eration by simply linking their attributes with itsown. By doing so, Domain attributes could get aglobal scope that reach anyone who trusts the AA.

8

We call this process Attribute Globalization. Onthe other hand, individuals can also use global at-tributes in the definition of their authorization poli-cies, Entity1.Attribute1 ≤ AA.Global1 is also a validattribute relationship. We call it an Attribute Local-ization.

In our example, when the University needs to makeProfessor Decisions “official”, it can introduce thisrelationship in the University Server,

University1.Pass Subject1 ≤ Prof1.Pass Global Subject1

Then, Professor1 is elected as the coordinator ofSubject1.

4.1 Attribute Federation Components

In our proposal, the Attribute Federation has two el-ements, the Attribute Authority and the AttributeOntology Server (AOS), which can be composed ofmany subordinated AOS as we will describe in thenext section. The AA manages Global Attributeswhereas the AOS manages the Domain Attributes.Therefore, the main element that the attribute fed-eration introduces, in contrast with traditional priv-ilege management infrastructures, is the AOS, whichis in charge of:

1. Managing Domain Attributes.

2. Storing relationships over Domain Attributes inthe system.

3. Checking attribute relationships based on thestored ontology, i.e. performing the trust nego-tiation autonomously.

Every entity is registered to an AOS which is incharge of checking the relationships over attributes.Registered users trust the AOS not to disclose theirattribute relationships neither to cheat them addingfake relationships.

Users may store new relationships in their AOSand/or check whether a relationship exists or not inany of the AOS of the Federation. The kind of re-lationships a user can upload to the AOS are of theform User1.Attribute1 ≤ User2.Attribute2, where

User1 is the ID of the user that is uploading the sub-scription. We call them attribute subscription and weread it as “attribute User1.Attribute1 is subscribedto attribute User2.Attribute2”. Attribute subscrip-tions are transitive in the sense that if Attr1 is sub-scribed to Attr2 and Attr2 is subscribed to Attr3,then we can infer that Attr1 is subscribed to Attr3.Attribute subscriptions is an analogous concept of Lilinked roles [9].

By using attribute subscriptions, users can relyon some other user attributes when defining theirown authorization policies, but they can not forceother users to rely on their own attributes. In orderto preserve the privacy of the attribute ontology, acheck for a relation of the form User1.Attribute1 ≤User2.Attribute2 is only answered to a user owningattribute User2.Attribute2.

In figure 11 Alice contacts Bob in order to retrievethe attributes needed to use the service she wants touse. This can be done contacting Bob directly or bychecking some other public service used by Bob topublish his authorization policies, e.g. a static webpage.

Figure 11: Attribute Federation Scenario

Once Alice knows the required attributes, she looksfor attributes that may be related to her own. If the

9

authorization policy is confidential, Alice will onlyget a specific domain attribute (in the domain ofBob) linked with the service she wants to access (e.g.Bob.service1), and the policy will remain confiden-tially in the AOS.

Then, she contacts the respective AOS in order tocheck whether there is a real relation between thecandidate attributes. This checking is done by Alice,while Bob is not involved. Once Alice has found arelation between one of her attributes and one of therequired attributes, she is ready to initiate a sessionwith Bob in order to use the service. In this way,Bob is only slightly involved in the protocol becausehe only has to locally check the response of the AOSinstead of having to check an attribute matching forall the users trying to use his web service.

In figure 12 the steps of the interaction protocolare detailed:

Figure 12: Interaction Protocol

0. Some time before the request, User2 sends itsattribute subscriptions to the Attribute Federa-tion. This is usually done at the initialization ofthe services offered by User2.

1. In the initial step, User1 gets a list with theattributes needed to use the services of User2either by sending an authorization request toUser2 or by checking them in some repository.In any case, after step 1, User1 knows which at-tributes he needs for being able to make use ofthe desired services.

2. Then, User1 sends the required attributes to-gether with the owned attributes to the attributefederation. Normally, only a few attributes aresent to the federation but the task of decidingwhich attributes are sent to the federation de-pends on the context of the request. Anyway, inthe worst case it could try with all the attributes.

3. When the federation receives a request, it triesto find a chain of attribute subscriptions so thatit could be proved that the attributes requestedby User2 are subscribed to attributes owned byUser1. In the case where there is any match-ing, the federation returns an attribute certifi-cate stating that the required attributes are sub-scribed to at least one of the attributes providedby User1, so User1 is entitled to use all thematching attributes. This certificate is issued bythe AOS which User2 is registered to because itis the only one he trusts.

4. At this stage, User1 is able to prove to User2that the requested attributes are subscribed tothe attribute it owns without having to send anyattribute. So, User1 sends the signed attributecertificate to User2.

5. User2 verifies the signature of the certificate tocheck if it becomes from its AOS and allowsUser1 to make use of its services in the casewhere everything is in order.

5 Storing and Updating at-tribute subscriptions

We try to adopt a syntax as close as possible to theone used in SAML, so our definitions become fairly

10

integrated with it. In particular attributes are repre-sented easily in SAML as they use the same philoso-phy than we do.

In SAML, the Attribute element has two XMLattributes, namely AttributeName and Attribute-Namespace. This idea of namespaces allows organi-zations to have security attribute names without thefear of any collision between names defined by differ-ent naming services. The first one can be identifiedwith our AttributeID and the second one reference,in some way, the user who defines the attribute. So,the following SAML attribute definition is equivalentto the attribute UserID.AttributeID(V alue).

<Attribute

AttributeName=AttributeID

AttributeNamespace=UserID>

<AttributeValue>Value</AttributeValue>

</Attribute>

From the UserID descriptor we should be able toderive a pointer to the AOS in which the subscrip-tions of this attribute are stored. Then an domainattribute credential is a regular SAML attribute as-sertion, where the attribute element is defined as be-fore.

An attribute subscription is an attribute statementin which the subject is also an attribute, then thesubscription

UserID1.AttributeID1(V alue1) ≤ . . .

. . . UserID2.AttributeID2(V alue2)

can be represented in a SAML alike notation usingthe following code,

<AttributeStatement>

<Subject>

<Attribute

AttributeName=AttributeID2

AttributeNamespace=UserID2>

<AttributeValue>Value2</AttributeValue>

</Attribute>

</Subject>

<Attribute

AttributeName=AttributeID1

AttributeNamespace=UserID1>

<AttributeValue>Value1</AttributeValue>

</Attribute>

</AttributeStatement>

This assertion has to be issued and signed by theuser to which the Attribute namespace UserID1points.

As mentioned, an attribute federation can be com-posed of many AOSs. In this way, attribute sub-scriptions are spread over the Federation instead ofbeing stored in a central server. Each entity in thefederation uses a unique AOS to store its attributesubscriptions, so finding attribute subscription chainsinvolves communication between different AOSs. Atrust relationship between AOSs in the Federation isneeded, so each AOS trusts other AOS answers toits requests. Ideally, each AOS stores only its ownattribute subscriptions, but for performance reasonsit may be desirable that each AOS stores a cache ofmost requested attribute subscriptions connected totheir own. Let us revise a sample scenario depictedin figure 13.

Figure 13: Sample scenario

In this scenario, Alice and Jack offer some ser-vices under an attribute federation in which AOS1and AOS2 are the corresponding attribute ontol-ogy servers for Alice and Jack. Alice has issuedsome attributes to Bob, as they are friends. Alicehas issued Bob an attribute certificate for attributeAlice.Friend. Later on, Bob tries to access some ofJack resources. In particular, one of the resourcesis granted to Jack friends, i.e. owners of attributeJack.Friend. Bob then has the choice to ask thefederation if attribute Jack.Friend is subscribed to

11

attribute Alice.Friend.To do so, Bob has to first prove to the federation

that he owns attribute Alice.Friend and then sendthe requested attributes he thinks are connected tothe one presented, in the example Jack.Friend. Theanswer is positive when the federation finds a validchain of attribute subscriptions,

Jack.Friend ≤ ID 1.Attribute 1 ≤ . . .

. . . ≤ ID n.Attribute n ≤ Alice.Friend

and proves to Bob that it exists by sending him anattribute certificate that he could send back to Jack.

If the AOSs stores only attribute subscriptions,the unique way to start searching for this chain iscontacting AOS2 and asking for all the attributesJack.Friend is subscribed to. Then, the pro-cess is repeated for those attributes until attributeAlice.Friend is eventually reached.

We can include some redundancy in the data storedin order to achieve a better performance. When a newattribute subscription is uploaded to the federation,the corresponding AOS not only stores the attributesubscription but also notifies (in the case the two at-tributes in the subscription do not belong to the sameAOS) to the other AOS involved, that a new subscrip-tion to one of its attributes is going to be added tothe federation. In this way, the notified AOS storesfor a given attribute, not only its attribute subscrip-tions but also the set of attributes subscribed to it.When doing this, the search for an attribute federa-tion chain can be done in a bidirectional way.

In fact, the storage of this extra information can beleft as optional but the notification should be done inorder to allow those AOSs interested in storing theinformation to do so. Then, if the target attributebelongs to an AOS that stores this extra informa-tion, the search can speed up. For the sake of con-sistency, when an attribute subscription is removed,a notification should be also sent to the AOS of theother attribute, so it can remove this attribute fromits records.

6 Conclusions

In this work, we establish a division between Globaland Domain attributes. Global attributes are definedin large Infrastructure as X.509 PMI, and are wellknown attributes. On the other hand, local decisionsdemand a different approach, based on the defini-tion of local attributes, that we name Domain At-tributes. These attributes are not directly managedby using the Infrastructure. So, by using domainattributes, we avoid using the underlying infrastruc-ture which can be computationally expensive in sev-eral environments as mobile devices. Moreover, Do-main attribute credentials are defined using SAML,an emerging technology based on XML.

The inclusion of domain attributes makes neces-sary to establish a new concept, called Attribute Fed-eration. The concept is similar to Identity Federa-tion but applied to Authorization sentences, avoidingidentity information exchange. In each Federation,a new element has been defined named AttributedOntology Server (AOS), in which entities store theirattributes and the relationships between them, i.e.attribute subscriptions, to simplify the authorizationprocess. The AOS is independent from the underly-ing PMI and can be easily distributed. It allows link-ing attributes from different users and reuse them inthe definition of authorization policies. In this way,we divide the authorization process in two layers, thatis, relation between users implemented by using at-tribute certificates, and relation between attributesimplemented by using attribute subscriptions.

References

[1] S. Landau and J. Hodges. A Brief Introduction toLiberty, August 2002.

[2] Isaac Agudo, Javier Lopez, Jose A. Montene-gro A Graphical Delegation Solution for X.509Attribute Certificates ERCIM News. SPECIALTHEME: Security and Trust Management No. 63,October 2005, pp. 33-34. ISSN: 0926-4981

[3] B. Kaliski. A Layman’s Guide to a Subset ofASN.1, BER, and DER, 1993.

12

[4] Isaac Agudo, Javier Lopez and Jose A. Montene-gro A representation model of trust relationshipswith delegation extension. In 3rd InternationalConference on Trust Management, iTrust 2005,volume 3477 of Lecture Notes in Computer Sci-ence, pages 116 – 130. Springer, 2005.

[5] D. Mundy and D. Chadwick An XML alternativefor perfomance and security: ASN.1. In IEEE ITProfessional, 6(1) pages 30–36. IEEE ComputerSociety Press, 2004.

[6] E. Yuan and J. Tong. Attributed based accesscontrol (ABAC) for web services. In IEEE Inter-national Conference on Web Services (ICWS’05),pages 561–569, 2005.

[7] William H. Winsborough, Kent E. Seamons andVicki E. Jones. Automated trust negotiation.In DARPA Information Survivability Conferenceand Exposition. volume I, pages 88–102, IEEEPress. January, 2000.

[8] William H. Winsborough, Jay Jacobs. Auto-mated Trust Negotiation in Attribute-based Ac-cess Control DISCEX (2) 2003: 252-

[9] Ninghui Li, John C. Mitchell, and William H.Winsborough. Design of a role-based trust man-agement framework. In Proceedings of the 2002IEEE Symposium on Security and Privacy, pages114–130. IEEE Computer Society Press, May2002.

[10] T. Bray, J. Paoli, C. Sperberg-McQueen, E.Maeler and F. Yergeau. Extensible Markup Lan-guage (XML) 1.0. Fourth Edition. W3C Recom-mendation. 16 August 2006

[11] Isaac Agudo, Javier Lopez and Jose A. Montene-gro Graphical Representation of AuthorizationPolicies for Weighted Credentials In 11th Aus-tralasian Conference on Information Security andPrivacy. (ACISP’06), pp. 383-394. LNCS 4058,Springer. Melbourne, Australia. July 2006.

[12] Arnaud Sahuguet, Stefan Brands, KimCameron, Cahill Conor, Aude Pichelin, Fulup

Ar Foll, Mike Neuenschwander. Identity manage-ment on converged networks: a reality check. InProceedings of the 15th international Conferenceon World Wide Web (Edinburgh, Scotland, May23 - 26, 2006). WWW ’06. ACM Press, NewYork, NY, 747-747.

[13] ITU-T Recommendation X.509.X509.Information technology Open systemsinterconnection. The Directory: Public-key andattribute certificate frameworks, March 2000.

[14] Kent E. Seamons, Marianne Winslett and TingYu. Limiting the disclosure of access control poli-cies during automated trust negotiation . In Pro-ceedings of the Symposium on Network and Dis-tributed System Security, (NDSS’01). February,2001

[15] William H. Winsborough, Ninghui Li. Safetyin automated trust negotiation ACM Trans. Inf.Syst. Security 9(3): 352-390 (2006)

[16] J. Hughes. SAML technical overview. Oa-sis. Document id sstc-saml-tech-overview-1.1-cd,2004.

[17] J. Hughes. SAML technical overview. Oasis.Document id sstc-saml-tech-overview-2.0-draft-03, 2005.

[18] M. Erdos and S. Cantor. Shibboleth-Architecture DRAFT v05, May 2002.

[19] Thomas Gruber. Toward Principles for the De-sign of Ontologies Used for Knowledge Sharing.International Journal Human-Computer StudiesVol. 43, Issues 5-6, November 1995, p.907-928.

13