Headlines
=Drummond
|
Identity Woman
|
The Tao of XDI
|
Identity for All
|
|
.Nat Zone
|
ID Commons
|
|
Technometria
|
InfoCard WebLog
|
|
Kim Cameron's Id Blog
|
@linksafe/+blog
|
|
inamers blog
|
Recent Headlines
| Automatically Building, Configuring, and Maintaining Comple... | Technometria | |
Image via Wikipedia I've been heads down for the last few weeks getting a project out the door for a new customer. As I mentioned, this involves creating a virtual appliance. I decided, due to the circumstances of this deployment that the best option was the build an appliance factory that is capable of churning out new virtual machines at will. I'm going to describe how I did that in this post. There are bascially three steps to creating a new image that runs the Kynetx Network Service (KNS): Create a new virtual machine Install packages and Perl libraries, create users, and otherwise configure the machine to run KNS Deploy the KNS code and test it I was exporing Kickstart files for automatically installing Fedora and CentOS when someone pointed me at Cobbler. Cobbler is a Linux installation server that is simply amazing. It includes templated kickstart files, DHCP and DNS servers, the ability to manage multiple distros and repositories, and a database for keeping it all straight. You start by importing distros and images, then define profiles that combine those with kickstart files, and finally create system definitions for each machine refering to profiles. I pnly needed one distro, one repo, and one kickstart, so I ended up with multiple systems hanging off of one profile. Once that's done, a command called koan (kickstart over a network) is used on the Dom0 machine to create virtual machines as defined by the system definitions cobbler. I carefully edited the kickstart file to create just the machine I wanted with the right packages installed. At this point, I was building new VMs and taking them down 20-30 times a day as I tested this. That's the beauty of automation--tacking up a machine is just dirt simple. I was lucky that I'd already invested considerable effort in Puppet recipes for building the environment that KNS need to run, so the second step was almost done. In fact, with just a few edits, I had Puppet building the new VMs up. The third step was also one that I'd spent some time on. I have a custom deploy script (in Perl) that deploys KNS code based on server role and takes care of all the little details like setting up the configuration files for the various servers. Every system is slightly different, but I think there's a definite distinction between machine setup, system configuration, and code deployment. The first creates a fairly standard environment, the second configures it to a specific purpose, and the third manages the code. Some thoughts on all of this: Some have asked "Why not put the code in Puppet (i.e. why use a deployment system)?" My answer is that code deployment is a dynamic process that I want more control of than puppet's automatic configuration provides. You could probably press Puppet into this, but it didn't seem to fit for me. I had to create a simple YAML-based configuration file for KNS to pull everything together. YAML was the right answer for this. I chose to put that configuration file in Puppet, but I think I'll pull it into the deployment process in the future. One missing piece is a database that everything can read system configurations from. Cobbler provides a light-weight one that may serve our purposes for a while, but something like iClassify is more flexible. Right now there's system information in Cobbler, Puppet, and the deploy script. There's a way to put additional attributes in Cobbler that we could use in other places. All of this--Cobbler, Puppet, and the deploy script--were installed and running on a virtual machine that we call the factory. That one image, once installed in Xen is capable of creating as many copies of each type of machine we run as needed. This can all be done on physical boxes too, of course, but I prefer the flexibility of virtual machines--even when only one will be running on the physical hardware. They can be moved, replicated, and managed with a lot more ease that physical hardware. Plus I have the ability to fire up new ones for QA or whatever without buying and installing new physical hardware. When a 8 core, 32 Gb box costs $4K, you can amortize that investment a lot with virtual machines. Startups need to be lean. Achieving that goal in a compute-intensive business requires automation. Fortunately with tools like Cobbler and Puppet, automating the build-side of your infrastructure is not only possible, but fairly easy. We manage several dozen machines with only a few hours a week of effort. What's more, adding a new box for load or experimenting is as easy as typing a few commands and waiting 20-30 minutes. |
||
| Starting a High Tech Business: Selling the Third Deal | Technometria | |
I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the nineteenth installment. You may find my efforts instructive. Or you may know a better way--if so, please let me know! I have a theory that the third deal matters more than the first two. Here's why. The first time you sell your product--your first deal--is always exciting. But let's be honest, it could be a fluke. If you beat the bushes long enough you're likely to find someone who'll buy almost anything. The second deal feels good because you at least can convince yourself that the first deal wasn't an accident. But the third time you sell your product you have confidence around a few important things: Proven repeatability - to get to the third deal you've proven that you understand what your selling and you're able to explain it in a way that people connect with. Turn the crank - at this point you ought to be able to "turn the crank" operationally and deliver. If you're still doing one-offs by the third deal, you need to ask yourself what will change by the fourth, eighth or 100th deal? You can't achieve scale without operational excellence. Know your price - On the first deal you're always a little unsure of the price you've set. Is it too high? Too low? Will you get laughed out of the room? By the third deal, you can go into pricing discussions with confidence. After all, two other customers have paid it--why won't everyone? I've found that to get any deal you usually have to put your ego aside. The sweetspot is when you've found (a) something you're good at, (b) something you like to do, and (c) something someone will pay for. A deal implies (a) and (c). If you have to cave at all on (b), then your ego's likely to get in the way of the deal. Putting ego aside is not always easy for techies to do. After all, you've spent years working on this and generally have dreams and even fantasies about how people will use it. Take a deep breath and realize: someone's willing to pay money for something you built. That's a good feeling. Go with it and enjoy the ride. |
||
| Annotating Anything | Technometria | |
Today I released build 299 of KNS. There are three important updates to KRL in this build. First, KRL now support literal hashes. Hashes are creating by enclosing comma-delimted name-value pairs in curly braces like so: {"foo" : "bar", "fizz" : 3, "flop" : [1, 2, 3]} Second, the annotate_search_results action has been modified to support two new configuration parameters: results_lister - (defaults to "li.g, div.g, li div.res, #results>ul>li") - jQuery selector for finding relevant results to annotate. The default finds search results for Google, Yahoo, and Bing. element_to_modify - (defaults to "div.s,div.abstr,p") - the jQuery selector for finding the element to modify within the results returned by the result lister. The default finds the main body of a search result.. These parameters give you the ability to find and annotate other items on almost any page that displays results. For example, the following action will annotate the paid search results in Google given an appropriately defined my_selector function. annotate_search_results(my_selector) with results_lister = "#mbEnd li" and element_to_modify = "a#an1"; Third, user-defined datasources are now more flexible. Previously, the arguments to the datasource function were assumed to be name-value pairs presented as strings. The function put them together to create a QUERY string. That wasn't as flexible as needed for path-based APIs. So now the datasource takes a single parameter of either a string or a hash: If the parameter is a string, then it is concatenated with the URL root given in the datasource declaration without modification. What you supply here, when appended to the datasource root URL must result in exactly the URL that you intend to call. If the parameter is a hash, then the has is turned into a properly formatted HTTP QUERY string with names 7 values delimited by an equals sign (=) to create a name-value pair and each name-value pair delimited by an ampersand (&): pre { tweets = datasource:twitter_search({"q": query}); } This allows path-based API calls to be created as strings and QUERY string calls to be created by either creating the string or putting the name-value pairs in a hash and letting the function create the query string. |
||
| CTO Breakfast Tomorrow | Technometria | |
Tomorrow is the CTO breakfast. It starts at 8am and goes to 9:30am. The location is, as usual, the Novell cafeteria. Sorry for the late notice; for some reason my calendar wasn't showing the Google calendar event. Luckily an email prodded me from my stoopor. The CTO breakfast isn't just for CTOs, but also for those who aspire to be CTOs or are interested in building high-texh products. The discussion is open-format. We decide what to talk about when we get there. You're welcome to bring your topic and bring it up. Here are the scheduled dates for upcoming meetings: No breakfast in July August 28, 2009 (Friday) September 24, 2009 (Thursday) I've created a Utah CTO Breakfast group at LinkedIn. You're invited to join. I hope to see you there! |
||
| Green Dam and the First Law of Identity | Kim Cameron's Id Blog | |
| Green Dam critic says, "Let's not allow the Green Dam software to block our way into the future." | ||
| Discovery Service Protability | .Nat Zone | |
| <p> In the previous post, I have shown that the Authentication Service can be made protable and that this is very important to prevent identity loss. One can prepare any number of XRD files and locate it anywhere he wants to make sure that his identity is not going to be lost on the net, as long as he can prove that XRD file is authentic. </p> <p> How do we prove it? </p> <p> One way to do it is to obtain the signagure from the Identity Attestation Service (IAS). The job of the IAS is to verify that the user is the rightful owner of the identifier and sign the XRD document presented by him.<br /> The resulting XRD may or maynot have the user’s core identifier, but MUST include the permanent identifier as <Subject> . Of course, the user can self attest but that means he has to have his own cert/key-pair and in general, his ability of being uncorrelatable at the RPs are lost because he has to expose his public key. </p> <p> So, the user now has a signed XRD. He can place it anywhere on the net. The trust is coming form the IAS, so if either the RP or Authentication Service do not trust the IAS, the flow breaks. In that case, the user should obtain a signed XRD from another IAS. </p> | ||
| Kynetx Open House and Demo Day | Technometria | |
Image via Wikipedia This Friday at 11:30, Kynetx will host an open house and demo lunch. If you'd like to see what we're up to, stop by, eat some pizza, see some demos, and chat. We're especially interested in getting more people developing on our platform, so if you'd like to try it out, we'll have sign up cards for anyone who wants them. We'll be at Kynetx World Headquarters in Thanksgiving Point. This map will give you directions; we're in Suite 275 (metal door). Please RSVP so we know how much pizza to buy. |
||
| Identity Loss with OpenID 2.0 | .Nat Zone | |
| <p>OpenID 2.0 has a problem such that permanent unique identifier generation is delayed until it gets to the authentication service. As a result, a user has no ability to change the authentication service. This implies that user cannot change the authentication service according to the authentictaion method requirement, he cannot enjoy the failover of the authentication service. Moreover, if the OpenID Authentication Service cease to exist, he will loose his online identity - He will become unable to login to many sites. IMHO, this is the worst weakness of OPenID 2.0. This is not theoretical. With several OP going away recently, this is the reality. </p> <p> This needs to be addressed. </p> <p> The way to address it is to leverage on the Discovery service, like XRI. The Discovery Service should return the permanent identifier, and authentication service should just use it. </p> <p> The flow is like this. </p> <h3>Case 1: User Specified Identifier</h3> <p> In this use case, the user does not care too much to be anonymous to the RP, so he enters his identifier to the RP. This is the basic case. </p> <ol> <li>The user access the RP and enters his identifier (Display Name/Alias).</li> <li>The RP finds out the discovery service for the identifer through appropriate bindings. (The simplest case is that the user supplied identifier is the location of his XRD.)</li> <li>The RP obtains the XRD document associated with the identifier.</li> <li>In the XRD document, there is a permanent and unique identifier (Canonical ID/Subject) as <Subject> and bunch of OpenID Authentication Services (AS). </li> <li>The RP choses the highest priority AS and creates AuthN request with Alias+Subject (AuthnReq).</li> <li>The RP sends AuthnReq to the AS. [1]</li> <li>AS authenticate the user by making him enter password etc.</li> <li>AS creates the AuthnResponse and sends it back to the RP.</li> <li>RP verifies the AuthnResponse</li> </ol> <p> Note that by the time it reached the authentication stage, the identifier is completely specified so it makes no difference when on switched the authentication service. </p> <h3>Case 2: OP Identifier</h3> <p>If the user cares to be anonymous, he needs to use OP identifer. This means there is an extra steps before.</p> <ol> <li>The user accesses the RP and specifies his Discovery Service (e.g., clicking on the button). </li> <li>The RP redirects user to the Discovery Service (DS). </li> <li>The User enters his identifier</li> <li>The DS generates an XRD with PPID (Pairwise Pseudonym Identifier) and returns it to the RP via browser redirect</li> <li>Upon receipt of PPID, RP starts the process described in Case 1 using this PPID as the user’s identifier.</li> </ol></p> | ||
| Green Dam goes in all the wrong directions | Kim Cameron's Id Blog | |
| The alternative is to construct virtual networks that are dramatically safer for children than the Internet as a whole | ||
| Enhanced driver?s licences too stupid for their own good | Kim Cameron's Id Blog | |
| Personal information readily accessible to anyone with simple card-reading technology |
||
| Building a Virtual Appliance: First Steps | Technometria | |
| Is anybody out there | The Tao of XDI | |
| Ethical Foundations of Cybersecurity | Kim Cameron's Id Blog | |
| Definitions for a Common Identity Framework | Kim Cameron's Id Blog | |
| Proposal for a Common Identity Framework | Kim Cameron's Id Blog | |
| CX First Step | .Nat Zone | |
| Tokyo Cherry Blossoms | .Nat Zone | |
| A Tail of (Disk) Corruption and Eventual Salvation | Technometria | |
| GM, Its Shareholders, and Slower Rusting | Technometria | |
| Information Cards in Industry Verticals | Kim Cameron's Id Blog | |
| You're Gonna Need It | Technometria | |
| More precision on the Right to Correlate | Kim Cameron's Id Blog | |
| Agile Roots, ErrorStack, Phones, and Games | Technometria | |
| Do people care about data correlation? | Kim Cameron's Id Blog | |
| The Right To Correlate | Kim Cameron's Id Blog | |
| The Permissioned Web: Open Does Not Mean Public Domain | =Drummond | |
| Star Trek: See It | =Drummond | |
| Why OPs do not offer Identity Attributes? | .Nat Zone | |
| Eric Norlin on Conferences Vs. Trade Shows | =Drummond | |
| Relationship between OAuth and CX, and OAuth vulnerability | .Nat Zone | |
| Contract Structure and System Identity | .Nat Zone | |
| Kantara Initiatve Launch | .Nat Zone | |
| Risk based security decisions and CX | .Nat Zone | |
| Increasing Members of OpenID Japan | .Nat Zone | |
| Adding another Hat | =Drummond | |
| Few niggling UI shortcomings of the iPhone | =Drummond | |
| Here comes the next Internet Identity Workshop | =Drummond | |
| Paul Trevithick on Password Cards | =Drummond | |
| FollowFriday Microtagging with XRIs | =Drummond | |
| What is SSO | The Tao of XDI | |
| Sensemaking Series on Internet Identity | =Drummond | |
| Bob Blakley?s Relationship Layer Paper Now Freely Available | =Drummond | |
| IDM 101 | The Tao of XDI | |
| What's in a claim? | The Tao of XDI | |
| The winner is: | The Tao of XDI | |
| The Claim Game | The Tao of XDI | |
| Resolution Revolution | The Tao of XDI | |
| Is this reputed to be a reputation? | The Tao of XDI | |
| I did my best... | The Tao of XDI | |
| The next stage | The Tao of XDI | |