Monday Aug 17, 2009

Securing REST Web Services With OAuth

It's been a while since the last OpenSSO article at Sun Developer Network (the excellent, three-part, Troubleshooting OpenSSO with Firefox Add-Ons), but Malla and Rick have come up trumps with Securing REST Web Services With OAuth.

The article recasts the tried and true 'stock quote sample' as a RESTful web service with access protected by OAuth via OpenSSO and Jersey (Sun's open source implementation of JAX-RS, aka JSR 311). This is technology that has hitherto only been demonstrated in a demo at JavaOne 2009, so it's great to see it being successfully applied here.

Go read the article and discover how OpenSSO, Jersey and OAuth combine to secure RESTful web services!

Friday Jul 17, 2009

links for 2009-07-17

Thursday Jan 15, 2009

Webinar - Access Management, Federation, and Secure Web Services with OpenSSO Enterprise

The (unfortunately) irrepressible Daniel Raskin and his sometime co-conspirator Jamie Nelson are presenting a webinar on Access Management, Federation, and Secure Web Services with OpenSSO Enterprise next Wednesday, January 21. Unfortunately, this will be a 'regular' webinar (no Second Life acrobatics this time!), but tune in anyway for all the latest on OpenSSO Enterprise.

Thursday Sep 11, 2008

From the Trenches - Security for Web Services

Over at Sun Developer Network today, Sidharth Mishra talks to Marina Sum about Security for Web Services. It's an interesting, high-level discussion, covering both the motivations for securing Web services and some of the standards and technology in the area. In particular, there's a useful explanation of the role of the Security Token Service (STS) in brokering trust between Web service consumers and providers.

Get yourself a nice cup of tea (or, if you must, coffee ) and give it a read.

Friday Apr 18, 2008

Fetching User Attributes With Identity Services

As I just blogged over at The Aquarium, Aravindan, Lakshman and Marina just published part 3 of their series on the new identity services functionality available now in OpenSSO and coming soon in Sun Federated Access Manager 8.0: Securing Applications With Identity Services, Part 3: User Attributes.

User attributes are key for delivering personalized services, and are often the main reason for authenticating the user in the first place. Go read the article - whether you're a RESTafarian or on the SOAPy side - you can quickly and easily put OpenSSO's identity services to work.

Tuesday Sep 11, 2007

links for 2007-09-11

  • The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring the User to disclose their Service Provider credentials to the Consumer. An example use case

Monday Aug 27, 2007

Apply Web Services Security to EJB Applications

At JavaOne 2007 earlier this year, Aravindan Ranganathan and Malla Simhachalam presented a hands-on lab titled Securing Identity Web Services. The lab showed how to provide different levels of stock quote service according to the identity of an end-user - authenticated users see real-time stock data while 'guests' see delayed quotes.

Since then, Malla, Mrudul Uchil and Marina Sum have written up the lab tutorial as a three-part series of articles showing how identity can be carried from an incoming web services request right through to an EJB. The sample application shows the request and response messages graphically, and provides links to the XML message data - a particularly nice feature that shows exactly what is going on.

Highly recommended for anyone putting together the pieces of web services, identity and EJB apps.

Friday Jul 06, 2007

links for 2007-07-06

Monday May 07, 2007

Identity and Web Services: A Marriage Made in Heaven?

Don Bowen, Wizard of IdM

Although I don't have a technical session this year, I will be up at JavaOne tomorrow, presenting "Identity and Web Services: A Marriage Made in Heaven?" with my good friend, the Wizard of IdM, Don Bowen, at 1:05pm in the Pavilion Theater. We'll spend about 20 minutes exploring the different ways that identity and web services impact each other. If you've heard Don on the Sun IdM podcasts, you know this'll be fun

UPDATE - here are the slides [PDF].

Friday Mar 09, 2007

Welcome, Mrudul!

A big shout down the corridor to Mrudul Uchil, lead engineer on Web services security and Java EE SDK/NetBeans Enterprise Pack integration in the Access Manager team. Mrudul just started blogging - anyone working with the new Web services security features in Access Manager 7.1 or looking forward to this technology appearing in OpenSSO needs to subscribe to Mrudul's blog.

Monday Feb 12, 2007

Slides from my RSA Conference session: "SOA-401 - Federated SOA: Harmonizing ID Security and Web Services"

I just uploaded the slides from my RSA Conference presentation last week: Federated SOA: Harmonizing ID Security and Web Services.

A few words of explanation on the opening slides... Sara Gates was originally booked to present in this slot. As you almost certainly already know, Sara left Sun a little while ago, and I inherited her slot. So, my opening gimmick was to introduce myself as Sara and then say "Of course, I'm not Sara, you can see and hear that, but how could a Web service tell the difference?". It was spoilt a little on the day by the RSA Conference announcer introducing me as Pat Patterson, but I made the point that if I had tried to introduce myself as Sara...

Anyway, in the presentation, I start from the position of unprotected web service interactions, working through transport-layer security via TLS/SSL to point-to-point message-layer security to Liberty Alliance's Identity Web Service Framework (ID-WSF), pointing out the different properties of each level. The session was recorded - I'm not sure if the recording will be publicly available, but, if so, I'll update this entry with a URL when it goes online.

Wednesday Sep 06, 2006

Sun Developer Network Channel - Identity Management Month

Sun Developer Network's SDN Channel this month focuses on Identity Management. There's a cool video featuring my esteemed colleague - Identity Guru Aravindan Ranganathan. Aravindan looks at some of the latest web services security features in Sun Java System Access Manager 7.1, bringing a new twist to that old staple web service sample - the stock ticker - by allowing only authenticated users to obtain real-time quotes. If you want to try this at home, the beta of Access Manager 7.1 is available now in the Java EE SDK download.

There's a whole load more useful information (and a link to a short article I wrote on open source identity at Sun) in the SDN Show Notes.

Wednesday May 24, 2006

Anatomy of a SAML-Secured SOAP Message

As promised, here is a dissection of the SOAP message from yesterday's post on the AM 7.1 Beta Secure Web Services Tutorial.

First, let's take another look at the secured message in its entirety:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <env:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-01.xsd">
      <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="s69f7e258e30da2b9b9f5799d4eb0c548782432bf" IssueInstant="2006-05-24T05:52:32Z" Issuer="patlinux" MajorVersion="1" MinorVersion="1">
        <saml:AuthenticationStatement AuthenticationInstant="2006-05-24T05:52:30Z" AuthenticationMethod="urn:com:sun:identity:Application">
          <saml:Subject>
            <saml:NameIdentifier>wsc</saml:NameIdentifier>
            <saml:SubjectConfirmation>
              <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
              <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
                <KeyValue>
                  <RSAKeyValue>
                   <Modulus>AIE1oq...</Modulus>
                   <Exponent>AQAB</Exponent>
                  </RSAKeyValue>
                </KeyValue>
              </KeyInfo>
            </saml:SubjectConfirmation>
          </saml:Subject>
        </saml:AuthenticationStatement>
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
          <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf">
              <Transforms>
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              </Transforms>
              <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
              <DigestValue>zdCY/1iqOMUJq/RvxsaDPWM4+7c=</DigestValue>
            </Reference>
          </SignedInfo>
        <SignatureValue>ApcX/D...</SignatureValue>
          <KeyInfo>
            <X509Data>
              <X509Certificate>MIICmj...</X509Certificate>
            </X509Data>
          </KeyInfo>
        </Signature>
      </saml:Assertion>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <DigestValue>Sccy9a3A7Ps27f3pf9adkRWuGvU=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>aE9vKM...</SignatureValue>
        <KeyInfo>
          <SecurityTokenReference xmlns="http://schemas.xmlsoap.org/ws/2003/06/secext" wsu:Id="STR1">
            <KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
          </SecurityTokenReference>
        </KeyInfo>
      </Signature>
    </wsse:Security>
  </env:Header>
  <env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
    <ns0:QuoteRequest>
      <Symbol>SUNW</Symbol>
    </ns0:QuoteRequest>
  </env:Body>
</env:Envelope>

It's pretty hard to see the wood from the trees here, particularly since there are two signatures in there. Here is a somewhat abstracted version:

Working from the inside out:

  • The SAML AuthenticationStatement contains data from a SAML authority concerning a subject - that is, the person/service/device/whatever whose identity is in question here. In the AuthenticationStatement we can see a Subject element containing a NameIdentifier (which we could use to refer to this subject in future exchanges with this SAML authority) and a SubjectConfirmation element. The ConfirmationMethod element tells us how the assertion is bound to the subject. In this case, it is Holder of Key, indicating that the SubjectConfirmation also carries a public key. Assuming we trust the SAML authority, we can be confident that anything we receive that is signed with the corresponding private key came from the subject. You can clearly see an RSA public key, with its modulus and exponent, in the KeyInfo element.
  • Moving down, immediately after the AuthenticationStatement is a Signature (white in the diagram). This is an enveloped signature over the parent Assertion. This signature binds the Assertion to the issuing SAML authority. It contains an X.509 certificate which we can use to verify the signature and decide if the assertion has come from a trusted SAML authority.
  • So, now we have an assertion that contains the public key of some subject known to a SAML authority. The next Signature element (blue in the diagram) is a detached signature of the SOAP Body. This signature binds the Body (and its payload - the actual stock request that the recipient is going to process) to the subject. This Signature does not contain an X.509 certificate. Instead, it has a KeyInfo element that references the earlier Assertion - the recipient is to use the public key in the Assertion to verify the signature.

The recipient thus has all the pieces it needs to verify that

  • The message was not tampered with in transit
  • The body was signed by some subject identified by a SAML authority identified by an X.509 certificate.

In this entry I've covered the stock request as it appears on the wire. Next time round I'll look at how Access Manager 7.1's JSR 196 provider makes all this happen in the web container (App Server) with no code in the required in your web service consumer or producer.

References

Tuesday May 23, 2006

Access Manager 7.1 Beta in Java EE Tools/NetBeans 5.5 Enterprise Pack

If you've been following Eric Leach's blog, you'll know that, just before JavaOne, we released a beta version of Sun Java System Access Manager 7.1 via a couple of bundles:

The former download is 132 MB, the latter 89 MB. The main difference between them seems to be that the Java EE 5 Tools Bundle includes NetBeans; NB EP 5.5 assumes you already have it.

Access Manager's role in this bundle is to secure web services. If you're thinking "Uh oh - this is that Liberty stuff they keep pushing at me; I've barely got my head around basic SAML assertions, let alone ID-WSF.", well - relax. We did show Access Manager working with Java Studio Enterprise and JSR 196 (Java Authentication Service Provider Interface for Containers) to secure web services via Liberty ID-WSF at last year's JavaOne (there's also a technical article on the topic); since then we have implemented WS-I BSP to secure 'plain vanilla' web services.

Here are my notes from installing the Java EE 5 Tools Bundle Beta and working through the Securing Web Services tutorial. I'm running Ubuntu 6.06 'Dapper Drake' Beta. Not an officially supported platform, but I like to surf the bleeding edge

  • Let's get started. I downloaded the Java EE 5 Tools Bundle Beta, chmod +x netbeans-5_5-ide-entpack-sdk-jbi-am-linux.sh; ./netbeans-5_5-ide-entpack-sdk-jbi-am-linux.sh and I'm into the installer. I need to tell the installer where I've put Java - it doesn't seem to know. Fair enough - this is not a standard system - I have at least three versions of Java floating around.
  • The installer prompts me for ports, passwords and trundles away for a while. On completion it reports that there were some warnings. I check /tmp/netbeans-5_5-installation-20060523143837.41310.log and it looks like the installer was not able to get to Access Manager (AM) at http://myhostname:8080/amserver/configurator.jsp. Ah - that's probably because it likes your system to have a fully qualified domain name (FQDN), e.g. myhostname.mydomain.com and I don't have a domain set. This is documented in the release notes - it doesn't seem to be a big deal, and I can get to that URL in Firefox, so we'll just carry on.
  • OK - surf to http://myhostname:8080/amserver/configurator.jsp and I get a nice configuration page:

    Those are the 5 parameters you need to set to configure AM. I left everything as default and (as expected from the release notes) got a server error. Putting a dummy domain on the end of the hostname did the trick and I'm at an Access Manager login screen.

    Cool! The simplest ever AM install/config
  • Login with the default amadmin/admin123 (we'll have to change that - I hate default passwords. We should add 'amadmin password' to the 5 configuration parameters) and I'm in the now familiar AM 7.x admin UI:
  • Ok - install and config done. On to the Securing Web Services tutorial. The tutorial notes are a little sketchy - I'll fill in the gaps here as I go along.
  • Grab the stockapp.zip sample source and put it somewhere sensible, as suggested in the tutorial. I get two directories, stockclient and stockservice. Cool.
  • Tutorial step 2 is missing an initial steplet - you need to go to the App Server admin console at http://myhostname:4848/ and login as admin with whatever AS password you selected at install. Hmm - I don't see a 'Runtime' tab, but I can see a running App Server (in fact, I already checked that it was running by browsing http://myhostname:8080/ and, of course, I wouldn't have been able to configure AM if it wasn't running. So, according to step 2c, I can safely skip forward to step 5 in the tutorial. Except that it seems like the next thing I have to do is in step 3.
  • Tutorial step 3 - yes - done this already.
  • Step 4 - ah - you will definitely want to do this - set AM to full message debug logging. On my system, the config file was at /home/pat/SUNWappserver/addons/amserver/AMConfig.properties. Beware - there is another AMConfig.properties file for the AM server - on my machine it's at /home/pat/AMConfig.properties. If you set message debug logging at the AM server but not in the AS addons, you won't get any of the diagnostic output described below. I know - I did exactly this first time round and spent several hours trying to figure out what was wrong. Change com.iplanet.services.debug.level to message and restart the App Server. Just go to wherever_you_installed_it/SUNWappserver/bin and do ./asadmin stop-domain; ./asadmin start-domain.
  • Step 5 - Run NetBeans and disable proxies as directed in the tutorial, since we'll be interacting with local services.
  • OK - now for some secure web service action... Start NetBeans and... Oh. NetBeans just shows me a blank window. That's not good. Google Google Google... Ah. I have XGL and Compiz eye candy installed. This forum post gives the answer - run the Xnest nested X server, the icewm window manager and then run NetBeans in the nested X session. Fair enough. Ubuntu recommends Xephyr rather than Xnest, so I grab that, icewm and.. great - we have NetBeans! [UPDATE: See this comment for a handy little script I wrote to run NetBeans in a nested X session.] Back to the tutorial...
  • Open the two projects. Cool - Web Service Provider (WSP) Security Configuration property page. Enable security, select SAML-HolderOfKey, sign reponses. Don't forget to change the password if you overrode the default AS 'adminadmin' password. Ooh - we'll have to fix that password entry field. This is beta, don't forget.
  • We can go look in the keystore, just to check that we are supplying the right password here, and that the s1as cert is there:
    pat@patlinux:~/SUNWappserver/domains/domain1/config$ keytool -list 
    -keystore ./keystore.jks -storepass password
    
    Keystore type: jks
    Keystore provider: SUN
    
    Your keystore contains 1 entry
    
    s1as, May 23, 2006, keyEntry,
    
  • Now to the client... Web Service Client (WSC) Security Configuration, enable security, SAML-HolderOfKey, verify response. Check that password again. And we're ready to run. Build and deploy stockservice as described in the tutorial. Build and run stockclient and we have a JSP ready for input. I had to copy the URL into the browser in my main X session, since Firefox wasn't happy running a second instance in the nested X session. I also had to change 'localhost' in the URL to my real hostname.
  • Now I just press enter to get a quote for SUNW and... I get a page of canned price data. It works!!! On my machine, ClientModule and ServerModule are in /tmp/amserver/, I can see real, honest to goodness WS-I BSP SOAP messages with SAML assertions in the headers. I've indented for clarity and elided most of the base 64 encoded signature and key info.
  • Here's the raw SOAP message as it leaves the client code (don't forget, the whole point of this is to abstract the security stuff out of the client/server code):
  • <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <env:Body>
        <ns0:QuoteRequest>
          <Symbol>SUNW</Symbol>
        </ns0:QuoteRequest>
      </env:Body>
    </env:Envelope>
    
  • And here is the secured SOAP message as it goes onto the wire:
  • <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://sun.com/stockquote.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <env:Header>
        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-01.xsd">
          <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="s69f7e258e30da2b9b9f5799d4eb0c548782432bf" IssueInstant="2006-05-24T05:52:32Z" Issuer="patlinux" MajorVersion="1" MinorVersion="1">
            <saml:AuthenticationStatement AuthenticationInstant="2006-05-24T05:52:30Z" AuthenticationMethod="urn:com:sun:identity:Application">
              <saml:Subject>
                <saml:NameIdentifier>wsc</saml:NameIdentifier>
                <saml:SubjectConfirmation>
                  <saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
                  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                    <KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
                    <KeyValue>
                      <RSAKeyValue>
                       <Modulus>AIE1oq...</Modulus>
                       <Exponent>AQAB</Exponent>
                      </RSAKeyValue>
                    </KeyValue>
                  </KeyInfo>
                </saml:SubjectConfirmation>
              </saml:Subject>
            </saml:AuthenticationStatement>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
              <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                <Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf">
                  <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>zdCY/1iqOMUJq/RvxsaDPWM4+7c=</DigestValue>
                </Reference>
              </SignedInfo>
              <SignatureValue>ApcX/D...</SignatureValue>
              <KeyInfo>
                <X509Data>
                  <X509Certificate>MIICmj...</X509Certificate>
                </X509Data>
              </KeyInfo>
            </Signature>
          </saml:Assertion>
          <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
              <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
              <Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
                <Transforms>
                  <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </Transforms>
                <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <DigestValue>Sccy9a3A7Ps27f3pf9adkRWuGvU=</DigestValue>
              </Reference>
            </SignedInfo>
            <SignatureValue>aE9vKM...</SignatureValue>
            <KeyInfo>
              <SecurityTokenReference xmlns="http://schemas.xmlsoap.org/ws/2003/06/secext" wsu:Id="STR1">
                <KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
              </SecurityTokenReference>
            </KeyInfo>
          </Signature>
        </wsse:Security>
      </env:Header>
      <env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
        <ns0:QuoteRequest>
          <Symbol>SUNW</Symbol>
        </ns0:QuoteRequest>
      </env:Body>
    </env:Envelope>
    

So - in the next thrilling installment, we'll walk through that secure SOAP message and see what each bit actually does.

UPDATE - here is that next installment.

Sunday Nov 20, 2005

Demonstration of Identity Web Services

Following on from my recent posting of a Federation Manager demo showing Liberty ID-FF federated single sign-on, here is a demo of Access Manager and Federation Manager I showed at a Liberty 'eGovernment Forum' in Dublin back in April.

This demo shows an employee of the 'Department of Health and Children' logging into the department's portal, visiting another government department, the 'Stationery Office', to obtain an official report, and having the Stationery Office query their 'home' department for a mailing address via the Liberty Identity Web Services Framework (ID-WSF).

This is a very simple demo, but it demonstrates some key aspects of Liberty ID-WSF:

  • 'Bootstrap' from federated web single sign-on (ID-FF) to web services (ID-WSF).
  • Use of the Discovery Service to locate a web service for a given user. (This takes place 'under the covers' - the bootstrap provides the service provider, in this example the Stationery Office, with the location of the Discovery Service and a credential to use on behalf of the employee. The service provider queries the Discovery Service for the location of the Personal Profile service).
  • Use of the Personal Profile Service to retrieve a user's profile attributes.
  • Use of the RedirectRequest protocol (specified in the Liberty ID-WSF Interaction Service Specification) to allow the employee's 'home' department to prompt for confirmation that address information is to be released to the Stationery Office.

Just click the screenshot below to view the demo...


Click to view Flash presentation

UPDATED 11/21/2005 - corrected Interaction Service to RedirectRequest protocol - see comments

About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today