[OpenID] Myopenid ax

Wed Jan 7 16:22:14 UTC 2009

Sounds ripe for someone to put dnoi in a box, load ciscos security agent for nt on it (as a host based ips), add a web console for multi tenant config, and even offer the same opx offloading protocol as does myopenid. The cert issue would have to solved though.

This would be quite similar to our saml box, where certs are configured per connection, and are dynamically stored in the java cert stores (of the platform). There the platform works optionally with an ethernet cryptobox (instead of soft crypto from sun) for https security mechanism support. then and only then does one need to indirectly do core host/vm config (needing reboot of host or vm, essentially)

The real key to all this is the url routing model: url interface for last mile to invoke, last mile to chandoff the now cloned orignators session onto the rp.

Ideally interfaces like opx would be open source, or shared, or cross licensed. But vendors being vendors, they always want to control that last mile as competitive advantage.

Not surewhat to do to standardize ax metadata. Perhaps opensource tools could take an ldif style text file and emulate an odbc/jdbc driver, that box.dnoi could then import into its web console...

________________________________
From: Andrew Arnott <andrewarnott at gmail.com>
Sent: Wednesday, January 07, 2009 7:59 AM
To: Peter Williams <pwilliams at rapattoni.com>
Cc: Martin Atkins <mart at degeneration.co.uk>; general at openid.net <general at openid.net>
Subject: Re: [OpenID] Myopenid ax

Hi Peter,

In response to:
What we get from the architecture is immunity from the assumptions the library designer has made in how he/she architected support for multi-tenant processing. DNOI is very web.config centric, from what I understand, being a "native" .NET concept.

Not to be too defensive of the library, I hope, but I'd like to suggest two counter points to your above statement.  First, DNOI only recently added support for reading settings out of a web.config file.  By design everything that can be done in a .config file for DNOI can also be done programmatically.  In fact, DNOI can even be used quite easily on a backend server without using ASP.NET<http://ASP.NET> at all.  If you still have concerns in this area I'd love to hear them.

Secondly, on the Provider side DNOI deliberately stays completely away from making decisions that the host site's policy works.  All DNOI asks the host site is "this user claims to be X.  Do you agree?" and the site can decide to go through whatever process it wants to determine that, and just answer DNOI's question (which may be much later, after redirects, or dialogs popping up, or whatever).  So again, if you can think of a scenario that DNOI doesn't handle because I've architected it too much, or the wrong way, etc, I'd love to hear about it.  I definitely want to make this library work for as many people and scenarios as possible.

Cheers. :)

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Wed, Jan 7, 2009 at 3:08 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

One thing that is VERY appealing about myopenid's domain service  is that it has a last mile + offloading architecture. This matches what we do today, with SAML-offloading to a websso switch (that we happen to operate ourselves). I find myself comparing that with investing in DNOI.

 If I look at openid as just another websso protocol, Id be very tempted to want to talk to a websso switch that does openid auth and ax, similarly. Ideally, the websso switch would support both protocols (saml2 and openid), but the nature of switching with url-based routing is that if no such box exists… its trivial to add yet another forwarding point, which routes to different switches for different websso outputs. While oneis switching/routing, of courselots of value-add can be being added (security of deep packet inspection firewalls with the ability to parse the URLs and HTTP flows at wirespeed, for example).

Think of it as policy based routing for IP, now with URLs. Depending on the traffic policy (I want high priority treatment for my voice traffic, and security over a MPLS VPN), the ip packet is routed to gateway X rather than Y. In the websso world, that translates as: consider the destination endpoint for websso recovered from metadata; now uses url-routing (rather than IP) as the basis for routing/forwarding decisions that invokes the right protocol at the local edge of the network. As the assertion passes across the openid core  (or the saml core),it exits the core at edge switch targeting the SP. At that point, it gets switched locally, perhaps ending up as an ASP.NET<http://ASP.NET> session with a FormAuth capability added for support.

What we get from the architecture is immunity from the assumptions the library designer has made in how he/she architected support for multi-tenant processing. DNOI is very web.config centric, from what I understand, being a "native" .NET concept. As a very large site also using Microsoft .NET, we are not - intentionally so. Thus native integration with DNOI is not appealing. If I had DNOI in a box, to be invoked with URL routing, I suspect it would be appealing. That box could be operating be on our site, sit in a SAAS location at an intermediate system endpoint, or be on a deep space probe with a 30m transmission delay . Obviously, the security of the routing/switching is important; and more difficult to achieve (particular when delays get more extreme) than architectures in which the endpoints are co-located with the server block… and sit within the block's own protection boundary.

What AX is missing is stronger metadata, that allows the offloaded switch to easily configure itself with its data sources. While XDI might be intended to ultimately play that role, it tends to  be seen as a control framework for the interaction of flows between parties , rather than be merely a convenient/optional repository of ax metadata that works across all vendor websso swtiches.

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Andrew Arnott
Sent: Tuesday, January 06, 2009 7:23 PM
To: Martin Atkins
Cc: general at openid.net<mailto:general at openid.net>

Subject: Re: [OpenID] Myopenid ax

DotNetOpenId supports the full AX extension, FWIW.  Any OP that runs DNOI should be able to easily add full AX support, including arbitrary push as well as fetch.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Tue, Jan 6, 2009 at 5:02 PM, Martin Atkins <mart at degeneration.co.uk<mailto:mart at degeneration.co.uk>> wrote:

Peter Williams wrote:

Delegate was probably the wrong term. Host a "private label op", would probably be a better term, borrowing from the world of hosted pkis. Myopenid has evidently built a multi tenant op, from what I can tell, much like we did in mls land: one sass pool of server side functions: 100+ configurations - one per tenant.

Okay, I understand what you mean now. I don't think we actually have a term for an OP that provides service in "your domain", so "private label OP" works, or perhaps "OpenID for your Domain" to steal the Google/myOpenID branding. :)

So I guess what you're looking for is an OP that:

 1. Provides OP services for an arbitrary, user-provided domain.

 2. Fully supports AX

For 1, the only provider I know of is myOpenID.

For 2, I know of no provider.

Pbwiki as a sp are obviously trying to go the same way, but I suspect their openid integration was not designed for the multi tenant model (from my trials, with wiki.openid.net<http://wiki.openid.net>).

As far as I'm aware, Pbwiki is only an RP, not an OP.

Even if they do act as an OP somewhere, I'd expect them to do it in the pbwiki.com<http://pbwiki.com> domain rather than on, say, wiki.openid.net<http://wiki.openid.net>.

_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general