I saw a commercial for robots tonight. Allow me to paraphrase:
I'm a neat freak...I'm obsesive compulsive...The Roomba is more intelligent than some people I know....It is a full featured robot...I know it's about to do a great service for me...the rumba finds more dirt than is humanly possible...I love robots...I don't know why I didn't buy one sooner.
I Love Robots!!!
Welcome!
Speaking of transforming claims, my good friend Pat is off in Tokyo at the moment speaking at Java ONE. As it turns out they've got a nice little posting of his bio for the converence:
アイデンティティ管理テクノロジーはこのセッションに注目しよう！（Pat Patterson氏）
Pat Patterson氏は、1997年にロンドンにあるソフトウェア開発会社のTrustbase社に入社。その後2000年にSunがTrustbase 社を買収し、以来Sunのアイデンティティ・管理製品グループのテクニカルアーキテクトを勤めています。フェデレーションとアイデンティティベースの Webサービス技術を中心に活動を行っています。JavaOne Tokyoでは２つのテクニカル・セッションのスピーカを担当。その内容について伺いました。
You will observe identity management technology to this session! (Pat Patterson)
Pat Patterson joins the Trustbase corporation of the software development company which London is in 1997. After that Sun purchases the Trustbase corporation in 2000, serves the technical architect of the identity management product group ever since Sun. Focusing on the federation and identity based Web service technology activity is done. With JavaOne Tokyo you take charge of the speaker of two technical sessions. You asked concerning the contents.
Craig Burton recently replied to my comments on his I Cry Post. While I generally agree with his sentiment on the metasystem, I have to take issue with the oversimplification of Infocard, Microsoft's implementation.
Craig states:
WS-* is not the encapsulating protocol. WS-Trust is the encapsulating protocol.
"The encapsulating protocol provides a technology-neutral way to exchange claims and requirements between subjects, identity providers, and relying parties."
What does WS-Trust do? It converts a token (in any format) into another token (in any format). You input an existing token, a request for a new token, and get back the new token. In otherwords, it is a token exchanger – between constituent systems.
Went down to Atlanta earlier this week for a Sxip install...ended up getting awfully nostalgic for Sun when I saw this sucker:
That's a $5 million dollar Sun StorEdge L8500. Basically, it's a giant array of backup disks serviced entirely by robots, complete with a built in fire suppression system.
In 4 years at Sun, I never actually saw one in the wild.
Interesting development...AllState is providing Identity recovery insurance:
http://www.allstate.com/landingpages/home/idtheft.aspx
"With Allstate's identity restoration coverage, you have a dedicated team to handle the complicated, time-consuming and tedious work needed to help restore your good name and your credit rating. They will make the phone calls, handle the paperwork and deal with the credit bureaus. Some services focus solely on credit card theft or offer limited expense coverage, but Allstate goes further to help protect your good name — and your time."
Benji at SalesForce.com had an interesting post today on the sforce blog. Here's the juicy part:
How do the clients, which all use web services to authenticate (using login and password today calling our login call), know where to get the SAML token from, in a standard way? There is no standard way to do this today, and even standards like WS-Trust don't seem to solve this problem. For example, you build a client using our web services apis. You deploy to all our customers. Customer A has one SAML provider. Customer B has another SAML provider. How does your code know where to go to get the token when deployed at customer A and at customer B, without configuring all of the clients with the location of the SAML provider?
Thought I'd share my little experiment with Dashboard Widgets
It's a little AJAX Soap Client - provide the payload for the SOAP body, and it will post a message with wsa:Action and wsse:UserNameToken. The response is displayed back.
This was sent to my service. As, you can see that InfoCard has automatically created a SAML 1.1 assertion bearing the email address provided in the selected InfoCard. What's not clear to me is what's going on with the action - its' using a wa-addressing action that is not defined in ws-trust...hmm. Anyone? I wish the body weren't mysteriously encryted....
[Update: Mark Wahl passed this along
"When requesting and returning security context tokens the following Action URIs are used
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT"
in WS-SecureConversation Feb '05.
Thanks Mark! ]
POST /simpleservice HTTP/1.1 Content-Type: application/soap+xml; charset="utf-8"; action="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT"
Host: 192.168.9.11
Content-Length: 12838
Expect: 100-continue
Connection: Keep-Alive
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<a:Action u:Id="_1" s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</a:Action>
<a:MessageID u:Id="_2">uuid:674467cc-10bd-4bd4-a4b6-fba565035d01;id=0</a:MessageID>
<a:To u:Id="_3" s:mustUnderstand="1">http://192.168.9.10:8080/simpleservice</a:To>
<dsig:X509Certificate xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">..../BjHqg==</dsig:X509Certificate>
<a:ReplyTo u:Id="_4">
<a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
</a:ReplyTo>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2005-06-20T00:44:36.734Z</u:Created>
<u:Expires>2005-06-21T00:44:36.734Z</u:Expires>
</u:Timestamp>
<e:EncryptedKey Id="uuid-dfeed4a3-da17-4699-80aa-dad0cccc082e-1" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/xx/oasis-2004xx-wss-x509-token-profile-1.1#X509ThumbprintSHA1">nNpk/FqUmDNX8fvv3bk9BVjY0eQ=</o:KeyIdentifier>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>GlV7KHIY0thaICqbatPYLaSRO4dyXxsR698bm9Po88K3iQpF1TvTC4HPp415eobwvUy7mLpM8XfOKEvfZ3fk0P4FjyXhtxQOnN35D7rCxVrnIu5zZqlNev9HqeqrUW05ocYgTGjD0RIV4XdRoScPiZU96EkzIfc6QsIFhGqo6RQ=</e:CipherValue>
</e:CipherData>
</e:EncryptedKey>
<c:DerivedKeyToken u:Id="_6" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<o:SecurityTokenReference>
<o:Reference URI="#uuid-dfeed4a3-da17-4699-80aa-dad0cccc082e-1"/>
</o:SecurityTokenReference>
<c:Generation>0</c:Generation>
<c:Length>32</c:Length>
<c:Nonce>z3cSc/jtJ+UCF5CEQ8xsLg==</c:Nonce>
</c:DerivedKeyToken>
<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionId="uuid-30365992-d9e4-46ad-9443-41b1aa1cc917" Issuer="http://schemas.xmlsoap.org/ws/2004/10/identity/issuer#self" IssueInstant="2005-06-20T00:44:35.718Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions x:Id="1" NotBefore="2005-06-20T00:44:35.500Z" NotOnOrAfter="2005-06-20T00:54:35.500Z" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://schemas.microsoft.com/2003/10/Serialization/"/>
<saml:AttributeStatement x:Id="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://schemas.microsoft.com/2003/10/Serialization/">
<saml:Subject x:Id="1">
<saml:NameIdentifier x:Id="1" Format="http://schemas.xmlsoap.org/ws/2004/10/identity#KeyThumbprint">9TGi5d7p2VFFnGtOZ5bmUwbpOJI=</saml:NameIdentifier>
<saml:SubjectConfirmation x:Id="1">
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:holder-of-key</saml:ConfirmationMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyValue>
<RSAKeyValue>
<Modulus>znzfPeulynSTfQRdMtkW3CTzR3G2T3l4YqI6Csdfq4huIEySzeCd1oEZ2aUtG/WjD1ZvgcNkaS8V6JuyU2+XGArNP/szM/KMIYDWa0vSkr1WpM+HUOK58fZXDQWTEaKzWJePMfOjUQefcg3CzK1uj1jM4pAVl6Hpv4862uIdzkWQ5SYV9mKu862Sc5RqF74KggMU3N9BzjPVWBrHzFIvJIQPsUWWRhb57N5qw2GzjPBDxK3ACKdkT/MA08Lnr4hSR/f827Zv363xN1BRinqcrfJE0GVr6/LL11qvZqaKEgd0NRnyKn+IR8VJbtpGMDcR03nZhkHFP87esFOD63zUIQ==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Attribute x:Id="1" AttributeName="http://schemas.microsoft.com/ws/2004/10/identity#E-Mail-Address" AttributeNamespace="http://schemas.microsoft.com/ws/2004/10/identity">
<saml:AttributeValue>cmort@sxip.com</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<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="#uuid-30365992-d9e4-46ad-9443-41b1aa1cc917">
<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>6EgVjHzVJvq5p8wA9CmRAa4428I=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>dHIsclXyt4S6/b485/Lw6t/0kAsJX3ctbJAtLZdSKoXiltOKLlOpnwrMESGDv6bwm3SjiadyF56MY0uWg8gqm65y8eO1o269CgQP4YB98LosaBnwzRXx63lzIp44rH6JcaOE0Cqq34P3cf5SxWC3BNaJpLfUbqrTw8wfHKIOxmc4bAaOMLMCV2QScbJQQYt1cE9b/mAtujl1cNzmGuDWVg2XyzwtE6HiPG8KvsgThDnz/ItzU2J9jfWBO7qXNDTM+EJt7LDn26HfixgxHDUm4W+wwxfhLGlER/KcNDWESOezBBd40diKpwIEALjZ/tAgLoGZPmnskFoaSLiDeeHTRQ==</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>znzfPeulynSTfQRdMtkW3CTzR3G2T3l4YqI6Csdfq4huIEySzeCd1oEZ2aUtG/WjD1ZvgcNkaS8V6JuyU2+XGArNP/szM/KMIYDWa0vSkr1WpM+HUOK58fZXDQWTEaKzWJePMfOjUQefcg3CzK1uj1jM4pAVl6Hpv4862uIdzkWQ5SYV9mKu862Sc5RqF74KggMU3N9BzjPVWBrHzFIvJIQPsUWWRhb57N5qw2GzjPBDxK3ACKdkT/MA08Lnr4hSR/f827Zv363xN1BRinqcrfJE0GVr6/LL11qvZqaKEgd0NRnyKn+IR8VJbtpGMDcR03nZhkHFP87esFOD63zUIQ==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</saml:Assertion>
<e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:DataReference URI="#_7"/>
</e:ReferenceList>
<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="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>t4R8JHI9sfYljoocDZ69/1HoAJU=</DigestValue>
</Reference>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>Q25uUOzeV9Aduvtw9eG9xMMNHrI=</DigestValue>
</Reference>
<Reference URI="#_2">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>f4UZdzH8TQGemsO2i2E+jIa6XDo=</DigestValue>
</Reference>
<Reference URI="#_3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>QFhRuh49ZnX8S4z8iKi3diz7UDE=</DigestValue>
</Reference>
<Reference URI="#_4">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>zaBQWq9U/zdzkimMsCHucawY8qc=</DigestValue>
</Reference>
<Reference URI="#_5">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>6am03LAQSO20LZsE07ikNHHAazo=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>ZFL4QT1wu4N58VamcSyL4cJxEj3cKBCWEwNR4P06FlLKiCseyVp2SWGe1qciQCUdhZd5zQMcuUTXxlod9uN3HUPQdHZSGvvM2wTLsDnBYL7KQXgO+VHOmupGWIhI+aZiIPq1+IXv9hi5qqFb9hQ6/xB9i0iO5KZFe3bqjt67QrZDgtsFqYLT+GVkdq+4dKf+HTXsXSylm6eS5ce6gpCalTu+6XTB/8eG/kRLxFUXci4CTyipl/NLTqrFmmiln/dzPjeGrskjf2WZdmg8oXw+of46mb04fpWrE3vUqX1lfA7kdCFL3gP0bEiRgiHXOa9PhaQdOt/nt0mzfq3YHwc85w==</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">uuid-30365992-d9e4-46ad-9443-41b1aa1cc917</o:KeyIdentifier>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>
<s:Body u:Id="_5">
<e:EncryptedData Id="_7" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:Reference URI="#_6"/>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>lR2D1YctHtOdkC0bNrfP4BrpIOJkG5GxWVKm+LzkY7+1RKxhpL5IC1Z10ON8Vsg9+B7a7/....qRneyxtQ==</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</s:Body></s:Envelope>
With all that out of the way, I finally can invoke my client, and get into the InfoCard interface, as well as take a look at the resulting message enrichement
When I invoked the client, the first thing it does is validate the Identity of the service using the cert in the addessPropeties. Assuming validity, the InfoCard UI is invoked. The first thing you seen is presentation of the relying party, and potentially their terms of service, as well as prompt to either agree to their terms, or cancel the operation. I wish I had a screen shot, but there doesn't seem to be a simple means to remove a relying party from your trust list, or change its settings. I expect this will show up in future versions.
Once I accepted the terms, I'm prompted to select an InfoCard. This shows the UI for infocard actually being invoked:
Click for a larger version
A few things to notice here
1) They track which card I've previously presented, and when I did it
2) They track what the relying party already knows about me
From here, I can choose a card to submit. This talks to a local STS in the current beta, and generates a SAML assertion, which is used to enrich the SOAP call...
InfoCard ends up getting invoked (at least in the Indigo use cases) via a custom binding in the services configuration file (app.config or web.config depending on selfhosting or was/iis hosted services)
The config file has 3 main sections required for InfoCard usage. The first is a custom binding. The binding section basically describes the protocol indigo will use to expose or talk to services in a declarative fasion. It ships with a number of default bindings for WS-I basic profile interop, WS-*, as well as some MSFT proprietary binary optimizations. You do have the ability to define a custom binding which gives you granular control over protocol. In order to use InfoCard, you seem to need to use a custom binding. Here is an example:
<bindings>
<customBinding>
<!-- Define custom binding for InfoCard. -->
<binding configurationName="InfoCardBinding">
<security authenticationMode="IssuedTokenForCertificate" contextMode="Session">
<federationParameters>
<tokenRequestParameters>
<xmlElement>
<wst:TokenType xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:wsid="http://schemas.xmlsoap.org/ws/2004/10/identity" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">urn:oasis:names:tc:SAML:1.0:assertion</wst:TokenType>
</xmlElement>
<xmlElement>
<wst:Claims xmlns:wsid="http://schemas.xmlsoap.org/ws/2004/10/identity" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wsid:Claim wsid:URI="http://schemas.microsoft.com/ws/2004/10/identity#E-Mail-Address"/>
</wst:Claims>
</xmlElement>
</tokenRequestParameters>
</federationParameters>
</security>
<httpTransport/>
</binding>
customBinding>
</bindings>
<behavior configurationName="TrustedCredentials" returnUnknownExceptionsAsFaults="true">
<channelSecurityCredentials>
<serviceX509Certificate findValue="Fabrikam" x509FindType="FindBySubjectName" storeLocation="CurrentUser" storeName="TrustedPeople" />
</channelSecurityCredentials>
</behavior>
<addressProperties identityType="Dns" identityData="Fabrikam">
<endpointHeaders>
<dsig:X509Certificate xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">MIIDwzCCAqu....==</dsig:X509Certificate>
</endpointHeaders>
</addressProperties>
Next, we need a simple client to go with my service.
using System;
using System.Collections.Generic;
using System.Text;
using System.Xml;
using System.ServiceModel;
namespace InfoCardClient
{
//This replicates the services contract - just raw Messages
[ServiceContract]
interface IGenericMessageChannel
{
[OperationContract(IsOneWay = true, Action = "*")]
void Send(Message msg);
}
class SimpleClient
{
public SimpleClient()
{
}
void SendMessage(IGenericMessageChannel channel, string input)
{
XmlDocument contentDocument;
contentDocument = new XmlDocument();
contentDocument.LoadXml("" + input + " ");
XmlNodeReader content = new XmlNodeReader(contentDocument.DocumentElement);
MessageVersion messageVersion = MessageVersion.CreateVersion(EnvelopeVersion.Soap11);
using (Message msg = Message.CreateMessage(messageVersion, "http://tempuri.org/ISimpleService/Receive", content))
{
try
{
channel.Send(msg);
}
catch (Exception e)
{
Console.WriteLine("Exception: " + e.ToString());
}
}
}
public void Invoke( string input)
{
using (ChannelFactorychannelFactory =
new ChannelFactory("InfoCardClientConfig"))
{
channelFactory.Open();
IGenericMessageChannel channel = channelFactory.CreateChannel();
SendMessage(channel, input);
channelFactory.Close();
}
}
}
}
Now onto some real infocard work. To begin with, I developed a simple webservice and client using Indigo. This service basically displays the raw SOAP which it is sent:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
//This is the Indigo namespace
using System.ServiceModel;
using System.Xml;
namespace InfoCardService
{
/**
Here, I'm using an interface to define the service contract.
Service contracts are explicit in Indigo, and can be distict
from application/class level contract as seen here.
*/
[ServiceContract]
interface ISimpleService
{
//A very raw service - interface accepts low level message type.
[OperationContract(IsOneWay = true)]
void Receive(System.ServiceModel.Message msg);
}
public partial class SimpleService : Form, ISimpleService
{
//selfhosting ServiceHost using generics to be types to my implementation
ServiceHostsh;
public SimpleService()
{
InitializeComponent();
}
private void button2_Click(object sender, EventArgs e)
{
sh.Close();
Application.Exit();
}
public void Receive(System.ServiceModel.Message msg)
{
MessageBox.Show("New Message:\n\n" + msg.ToString());
}
private void Start()
{
sh = new ServiceHost();
sh.Open();
}
static void Main(string[] args)
{
SimpleService service = new SimpleService();
service.Start();
Application.EnableVisualStyles();
Application.Run(service);
}
}
}
Making a WS-Trust RST Issue call from Indigo is pretty simple. I defined a custom security binding with a endpoint reference and presto...ws-trust.
To do this, I added this to the federationParameters section of a custom binding security element:
<endpoint address="http://192.168.9.10:8080/simpleservice" bindingConfiguration="WSTrustBinding" bindingSectionName="wsProfileBinding"/>
I then reference the binding from my client endpoint reference, and when I invoked my client, it makes this call:
POST /simpleservice HTTP/1.1
Content-Type: application/soap+xml; charset="utf-8" action="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue"
Host: 192.168.9.11
Content-Length: 1304
Expect: 100-continue
Connection: Keep-Alive
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</a:Action>
<a:MessageID>uuid:6e984807-8946-4201-a757-2b6829a5fdb4;id=0</a:MessageID>
<a:To s:mustUnderstand="1">http://192.168.9.10:8080/simpleservice</a:To>
<a:ReplyTo>
<a:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:Address>
</a:ReplyTo>
</s:Header>
<s:Body>
<t:RequestSecurityToken Context="uuid-58ae93d3-a412-4ee4-97ab-288bc880b35a-2" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
<t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</t:RequestType>
<t:BinaryExchange ValueType="http://schemas.microsoft.com/net/2004/07/secext/WS-SPNego">TlRMTVNTUAABAAAAt4IY4gAAAAAAAAAAAAAAAAAAAAAFAs4OAAAADw==</t:BinaryExchange>
<wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<EndpointReference xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://schemas.microsoft.com/2003/10/Serialization/">
<Address>http://192.168.9.10:8080/simpleservice</Address>
</EndpointReference>
</wsp:AppliesTo>
<t:KeySize>256</t:KeySize>
</t:RequestSecurityToken>
</s:Body></s:Envelope>
The InfoCard API is pretty straight forward (and I suspect in flux). There are only really 2 classes to pay attention to:
Microsoft.InfoCards.InfoCardClient
public static System.ServiceModel.Security.GenericXmlToken GetToken(System.ServiceModel.EndpointAddress endPoint, System.Collections.Generic.IEnumerablepolicy, System.Xml.XmlElement requiredRemoteTokenIssuer)
public static void Manage()
public override System.IAsyncResult BeginGetToken(System.ServiceModel.EndpointAddress target, System.AsyncCallback callback, object state)
public override System.ServiceModel.Security.Tokens.SecurityToken EndGetToken(System.IAsyncResult result)
public override System.ServiceModel.Security.Tokens.SecurityToken GetToken(System.ServiceModel.EndpointAddress target)
public InfoCardTokenProvider()
public override bool TryApplyIssuedTokenParameters(System.ServiceModel.Security.IIssuedTokenParameters parameters)
public override bool WillGetTokenCompleteSynchronously(System.ServiceModel.EndpointAddress target)
Since I'm un-employed this weekend (I'm starting a new job at Sxip Identity on Monday), I thought I'd sit down and poke around the new Microsoft.InfoCards API and Indigo.
To start with, I suppose I'd better state up front that I haven't ever used Windows as my primary Desktop OS, and this is my first dive into C# as well. Fortunately, it seems to be enough of a Java clone that the learning curve is really quick...it feels a lot like Java 1.5.
Invoking the InfoCard UI:
My first step was to get the WinFX CTP and VisualStudio Betas installed. This was pretty straightforward, but make sure you have the latest of each, as there are some linking dependencies in the .NET build that require a specific combination. Also, I'd recommend the express version of Studio, as the full version is several GB.
To start out hacking with InfoCard, I thought I'd simply invoke the InfoCard UI. The simple way to do this is to hit the ControlPanel -> Digital identities. (Note that you can start the system by running: net start "InfoCard Service" at the command prompt if the system is not started for you) The result is the following wireframe UI:
Click for a larger version
It's also quite simple to invoke this via code. To do so, you can simply use the Manage() method on Microsoft.InfoCards.InfoCardClient. Simply create a new Console application, and add a reference to the Microsoft.InfoCards assembly. Then, the following code will invoke the InfoCardUI
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.InfoCards;
namespace ManageInfoCard
{
class Program
{
static void Main(string[] args)
{
InfoCardClient.Manage();
}
}
}
I recently ran across an old book of Barksdale-isms from Netscape. I thought I'd share some of the choice ones.
Today's - The three rules of snakes:
Mara and I just got back form a week on MV. I went a little crazy with the camera, and ended up with a flickr photoset that's 140+ large. Enjoy!
My good friend hamlett passed along some must haves for proud 'sconies: Illannoy.com
...has finally gone open-source!
http://directory.fedora.redhat.com/wiki/Main_Page
It's refreshing to see something positive coming out of the ashes of Netscape - between embedding IE in Netscape 8, and the low-cost ISP ads...
I finally got around to putting together a slide show of our recent Mexico trip. I just can't say enough nice things about Tulum.
An interesting identity question that I pass on the way to work each day:
Given that the artist poses the question in the first person, I tend to trust "me." As soon as you direct the question from the third person, it's the asserted attributes of the entity that are trusted, and not the entity itself.
Of course, as the always excellent read of luke razzel's blog points out, names can be a bit tricky too.
Paul Graham has 3 Simple Rules for building a startup:
I was recently using one of BEA's many SOAP stacks, and discovered that while comprehensive, their documentation isn't actually accurate...a particularily frustrating combination.
Lucky for me, I happen to sit next to the guy who used to be in charge of all of them. He clued me into the site of manoj, who writes the server stack - apparently its where support sends people.
If you're using web services on weblogic...you'll need this: http://www.manojc.com/
Here is an intersting aspect of my digital identity...online records of the skateboarding ticket I received back in college.
I'd be a little scared by this if the State of Wisconsin were at all threatning...that is assuming you're not a feral house cat Ahh....wisco...
If you're feeling especially geeky today, you can query my WI criminal record over SOAP
Another interesting scientific paper (don't worry - the last for awhile) is the Google Labs write up on GFS.
As I read this paper, I was struck with the architectural similarities to Directory Server as well as work we'd done on a system called the "distributor'". While many Directory servers have reasonably good vertical scaling capacity, there is a certain point where the management functions of a system becomes too fragile, sequential operations take to long, and the statistically low write volumes (that tend to be a directory design center & increasing liability) still result in large write volumes as a function of a user population. Deployment of a single physical system, while technically viable, starts failing to meet design constraints in ways which simply aren't an issue at low scale. Ultimately, decomposition of data into smaller logical "chunks" not only allowed better aggregate write throughput, but also allowed parallelization of time dependent operations (backup, recovery, etc).
I had a lot of fun working on this with some of my favorite people there - Steve Shoaff and Neil Wilson. I hope that Sun let's this loose. - in the meantime, read about GFS.
Here's an intesting read on how ideas emerge from holes.
So, why's this the first post to my blog?
Having spent 5 years in the IdM industry, and having done so at one company (err...3? Netscape/iPlanet/Sun? ), I recently decided to jump through a structural hole, and see what was on the other side. As it turns out, it was a small SOA startup.
8 months later I've decided to jump on the bandwagon, and I've decided to call my blog xmldap - a nice hybred between my old and new industries, which is what I intend to write about...I hope you enjoy.
The paper itself does a nice job articulating (and partially quantifying) the intangible social capital assigned to social supernodes (see the 6 degrees of bowen ). As the new generation of emergent identity systems gets designed, we must provide for liberal acceptance of tokens/assertions/claims. Physical manifestations of social networks like LinkedIn have tremendous potential as transitive "trust" overlays...picture a Web of Trust model without key management. Some powerful Identity claims exist in untapped form (eBay reputation, social webs, etc ) - as in any good protocol design, let's be liberal with what we accept.
