A RESTful Approach to Identity-based Web Services · 2009. 6. 8. · A RESTful Approach to...

A RESTful Approach to Identity-based Web Services

Marc J. HadleyHubert A. Le Van GongSun Microsystems, Inc.

1Thursday, June 4, 2009

Outline

> Identity-based web services intro> RESTful ID-WSF> OAuth Extensions> Permissioned Data Sharing

2


Identity-based Web Services?

3



3

Who

SenderInvokerRecipientTarget

Identifying the parties



3

Who



What LocatingAddressing

Resource



3

Who




Resource

HowTransportPhilosophySecurity

Framework



3

Who




Resource

HowTransportPhilosophySecurity

Framework

Why AgreementPolicy

Privacy


One way to look at it

> You surf the web• Authenticated once• Seamlessly logged in to other sites

> You purchase airline tickets &move to another country• Your online calendar is updated• Your magazine subscription follows

4

Single

sign-On

Delegat

ed

Authorization


Evolution & Issues

5

# my identities

# online apps

# onlinerelationships


Evolution & Issues

5

# my identities

# online apps


Web browsing, search...1


Evolution & Issues

5

# my identities

# online apps



n

n

Online banking, email... 2


Evolution & Issues

5

# my identities

# online apps



n

n


Photo sharing, blogs, IM... 3

y

x

z


Evolution & Issues

5

# my identities

# online apps



n

n


Photo sharing, blogs, IM... 3

y

x

z4 What we want!!


A Continuum of Solutions

6

> Delegated Authentication• Single Sign On

> Attribute Exchange

> Delegated Authorization• Sharing of attributes

WS-Federation

OpenIDSAML

Liberty ID-WSFOAuth

WS-*

Some cover it all...


RESTful ?• REST is an Architectural Style

• Set of constraints you apply to the architecture of a distributed system to induce desirable properties

• RESTful Web Services• Application of REST architectural style to services that utilize Web

standards

• Key elements• Resources identified by URIs• Standard set of methods with well-defined semantics• Resource representation format identified with media types• Responses contain links that clients traverse to navigate application

state• Stateless communications

7


Why RESTful ?• Reach

• Services easily consumed by a variety of clients

• Alignment• Services are part of the Web• Services work well with existing infrastructure• Bookmark-able• Browser friendly

• Scalable• Horizontal scaling• Cache friendly• Straightforward failover

• Reduced coupling8


First Foray: RESTful ID-WSF

> Starting point: Liberty ID-WSF 2.0• Identity-based Web Services Framework• Builds on top of Identity federation (e.g. SAML)• Provides framework for

• Data sharing• Privacy & security protection• Some nice features like

• Data service template (DST)• Interaction service• People service

9

http://projectliberty.org
































































10

Typical Scenario



Same overall approach• Service Association

• Service Discovery

• Service Invocation

11

1

2

3

But...


RESTful Approach - Some key differences

> Resource location• Resource in SOAP == service endpoint + owner identity• Resource in REST == represented by an endpoint (URI)

> URI (a resource) MUST be cachable & bookmarkable• Correlation issues that potentially require additional security

mechanisms> Resource Access

• SOAP operations define in, say Liberty ID-WSF, overlap with HTTPʼs CRUD operations

12


RESTful ID-WSF - Service Association

> A 2-steps process• Registration of a service metadata to a Discovery Service

13


RESTful ID-WSF - Service Association

14


RESTful ID-WSF - Service Discovery

15


RESTful ID-WSF - Service Invocation

> Classic use of HTTP CRUD operations but...• Add a security token obtained at discovery time• Possible use of XPATH-based queries

• Within the body of the message• As parameters of the URI

16



17


Approaching from Another Angle: Extending OAuth

OAuth in a Jiffy...• HTTP-based protocol• Delegated Authorization

• Allow a service consumer to access a resource hosted at a service provider

• Browser and non-browser based user authZ / consent• Signature mechanism to secure HTTP messages

However, OAuth core does not support our use cases...

18


Approaching from Another Angle: Extending OAuth

• What follows are ideas being worked on• Conveying identity tokens• Provisioning & discovering services

• Leveraging XRDS to describe a userʼs services

• VRM / Permissioned based data sharing

19


Extending OAuth - Conveying Identities

20

Hike.com(Alice)

Event.com(Bob)

Alice



20

Hike.com(Alice)

Event.com(Bob)

AlicePortable Contacthiking friends



20

Hike.com(Alice)

Event.com(Bob)


IdP/OP(Alice)

ID token A

ID token A



20

Hike.com(Alice)

Event.com(Bob)


IdP/OP(Alice)

ID token A

ID token A

ID token A

OpenID IDor Email A...



20

Hike.com(Alice)

Event.com(Bob)


Portable Contact

membership queryIs A in set for B?

IdP/OP(Alice)

ID token A

ID token A

ID token A

OpenID IDor Email A...


Extending OAuth - Service Provisioning

21


Permissioned Data Sharing

22

site that

consumes data

disclose


Typical Federated-Identity Solution

23

identity provider,discovery service...

consumer,relying party,web service consumer...

service provider,attribute authority,

web service provider...

disclose store

authorize


OAuth Solution

24

consumerservice

provider

disclose store

authorize


Functional Requirements> Support the notion of a "relationship management" service that

an individual can access as an interface mode separate from authenticating to networked applications

> Allow an individual to select policies and enforceable contract terms that govern the granting of responding-service access to requesting services

> Allow an individual to conduct short-term and long-term management of access relationships, including modifying the conditions of access or terminating the relationship entirely

> Allow an individual to audit and monitor various aspects of access relationships

> Allow requesting services to interact directly with responding services in a fashion guided by policy while an individual is offline, reserving real-time user approval for extraordinary circumstances

> Allow requesting services to interact with multiple responding services associated with the same individual

25


26

consumerservice

provider

relationshipmanager

authorizecontract

disclose store

Relationship Manager Solution


identity provider,discovery service

26

consumerservice

provider

relationshipmanager

authorizecontract

disclose store

Relationship Manager Solution


27

High-Level Overview of Interactions


28

• Further use case development• IIW and other venues...

• Protocol development in Kantara• Coordinating with related communities• OAuth, CX, XACML, uApprove, Mine!, Mydex, r-cards...

• Seeking collaboration on implementations

• OpenSSOʼs OAuth extension (imminently)• Other open source projects

Next Steps for This Work


Useful Technologies...

> Jersey (https://jersey.dev.java.net)RESTful framework for Java developers

> OAuth Signature Library (both client & server)Java-based - smooth integration with Jersey (filters)RESTful implementation.

> OpenSSO (http://opensso.org)Access management, SSO etc.

29


http://jersey.dev.java.net

http://jersey.dev.java.net

http://opensso.org

http://opensso.org

Conclusion

> Still early days for this work> Lots of compelling use cases> Protocols under active developments

• OAuth (community & IETF),• Kantara Initiative etc.• XRDS• ...

30


Marc J. HadleyHubert A. Le Van Gongmarc.hadley at Sun.Comhubert.levangong at Sun.Com

http://weblogs.java.net/blog/mhadleyhttp://blog.levangong.com


http://blogs.sun.com/mhadley

http://blogs.sun.com/mhadley

http://blog.levangong.com

http://blog.levangong.com

A RESTful Approach to Identity-based Web Services · 2009. 6. 8. · A RESTful Approach to...

Documents

Transcript of A RESTful Approach to Identity-based Web Services · 2009. 6. 8. · A RESTful Approach to...