Profil de PeterPeter's ruminationsPhotosBlogListesPlus ![]() | Aide |
|
27 avril Shibboleth2 ECP for IIS7/Windows 2008To allow IIS7 (via the shib_isapi handler) to invoke the NativeSP in "handler" mode (so Shib2 act as a layer 5 protocol engine, rather than web-session middleware) and then support a trial generting a SAMLRequest using ECP and PAOS, I did the following 1. in isapi src, alter code lines as follows A pair<bool,long> res = stf.getServiceProvider().doAuthentication(stf, true); // note true for 2nd parm B dynabuf handlervar(256); // define val as global, and have CRT static alloc space C GetHeader(pn,pfc,"url",handlervar,256,false); // add line to ShibTargetIsapiF constructor, after existing GetHeader(url). Fast hack to store inbound querystring as global char* in handlervar D // The filter never processes the POST, so stub these methods. 2. in isapi src, comment out any undesirable, "non protocol" features g_Config->setFeatures( 3. In a shibboleth2.xml SP config file generated by TestShib harness, ensure default SessionInitiator has (undocumented) attribute ECP="true" <SessionInitiator type="SAML2" Location="/TestShib" ECP="true" // note case sensitivity of ECP 4. Invoke trial usin tool like curl(1) ...using GET to induce protocol run, where providerId parameter is demonstrably set to "none" to showcase the ECP scenario. Run-time mux/demux requirements for trial varied by changing "TestShib" and applicationId=<val>. Invokes protocol engine for layer 5 S-SDU/initiate, in raw mode. https://win8pw.rapattoni.local/Shibboleth.sso/TestShib?applicationId=default&providerId=none 5. Ensure HTTP Request has conforming http request headers (taken verbatim from SAML2 documentation/latest-errata) Accept: text/html; application/vnd.paos+xml Unless I missed some of my code hacks, this produces a trial as follows. Since this is the first time in 12 months of trying with 3 windows products that I've got this far with ECP ...Im pretty happy with Shib2! Thanks!
_________________________ From: Peter Williams Sent: Sat 4/26/2008 1:11 PM To: shibboleth-users@internet2.edu Subject: RE: TestShib not responding to ACSURL I've moved on in my experiment (changing Shib2 code to suit), hopefully exploiting a response on a different thread. It noted that one can initiate a (SAML2) protocol handler using URIs of the form: Feedback on OpenLiberty ECP plugin for Mozilla FirefoxUsing instructions at http://openliberty.org/wiki/index.php?title=ECP_Plugin_Documentation&action=edit, I have the capability to now mostly build the ECP extensions, but have not succeeded to run the ECP plug-in on windows2008 Enterprise Edition. Some pretty raw feedback follows:-
The notes might want to suggest an SP site, with which to make a trial - and/or define a means to know at least that the extensions is at least loaded into Firefox. _________________________ SemWeb authenticated data flows, concerning OpenID and ECP"How to apply openid to linked data and semweb agents?" is a harder question to answer than I ever imagined it would be. Over the last 12 months, I've built up a pretty complete design-history for myself, linking up a rich history of open standards SSO schemes ending at OpenID2. This started with the chained SSO model in 1986-era X.500, through Kerberos-centralist world of the NOS-based network, through distributed PKI-based military messaging a la MISSI/P.772, through RSA's inter-domain cookie issuing by isap/nsapis allow for remote reliance on SecurID tokencodes, to S2ML/SAML push/pull artifacts and websso, to recent Liberty ID-FF profiling for different classes of UAs, to OpenID1 for UCI and OpenID2 for UCI & XRI-based authority resolution environments. This of course just all leads to Henry's own profiling efforts of all that "wealth of stuff" ...for the world of the "linked data". Since OpenID Auth v2 seems rather weak as it applies to all the various flavors of web services (or comes with rather too much javascript or DOM-centric religion, where it does apply), I've been focusing on SAML2's "ECP view" of the world - as a stepping stone between the web culture for SSO (that is now commodity) and web services SSO culture (that is emerging - in as yet heavyweight models). In parallel, I'm trying to see which bits of Liberty/SAML2 IDP discovery (via common domain cookie services) are actually useful and viable, as they MIGHT apply to ECP trust-fabric switching. My notion is that once something all works, viably, then one can turn back to OpenID extensions standardization to bring down the bar (and the cost). In Figure 5 of http://www.projectliberty.org/liberty/content/download/319/2369/file/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf, we see a diagram of somewhat similar complexity to your own original diagram of "OpenID2 meets Semweb agents"- to which you later drew contrasts. Of course, the Fig 5 diagram targets a custom UA (not a browser), much like a semweb UA, perhaps. I don't fully understand the rationales of all the design elements and the messages shown in that diagram; and I don't fully understand which specs control which bits of the ECP profile's protocol stack (SAML2 contributes a bit, as does the Liberty-controlled PAOS spec, as does Liberty ID-FF - apparently). But I _have_ made some practical progress - trying to see if ECP technology from open sources is approaching commodity status - such that the likes of me ...with low-end programming skills ...can now also participate, _finally_. On that practical path, I do now "amended" the open source Shib2 SP server src, so it essentially does steps 1 - 3, using a developer UA. And, I built Peter Pritchard's openliberty ECP plugin for Firefox - which, placed in a browser container, would do the "signal handling" assumed in the space between steps 3 and 4. With a bit more effort or help, I may even get it to work and actually talk to the Shib2 SP-side SAML server. But I'm already worried, since it brings alot of Mozilla-relegion and implementation-centric baggage. Once all that works once, however, I'm likely to abandon the effort to actually apply the openliberty client - since it focuses on browser-based, user-centered UI for Selecting IDPs, in a "lets-go-compete" with cardspace and JanRain's idselector.com mission). Rather, I may to back to applying my own data-centric/metadata-aware UA as the ECP agent, which is similar to your semweb user agent I suspect. And there, "trustworthy" metadata will guide the switching path chosen through the SP->IDP trust fabric, rather than users. Now, I have various patented techniques and other IP I can (privately) call on to accomplish automatic, trust-metric-based switching in an XRI-style tree walking environment, and you of course have the alternative W3C:WOT and PGP traditions to call on - addressing the FOAF tradition. Once the overall flow is right using a variety of modern, trust fabric infrastructures, perhaps the trick will be to then cast it all in terms of simple, OpenID extensions. _________________________ From: Story Henry Sent: Mon 4/21/2008 8:07 AM To: OpenID General Subject: Re: [OpenID] OpenId sequence diagram _______________________________________________ general mailing list general@openid.net http://openid.net/mailman/listinfo/general sharing XRI between SAML and OpenID; extending the XRD schemaLooking for what SAML2 and OpenID2 each do best, and where they act in common with regard to security handling rules for their respective "Authentication Request protocols", I noted the following in [1]
First, saml and OpenID are similar in that both characterize the fundamental controls in their handshake design in terms of "requests" (not responses). Second, in the SAML case, metadata may be signed or not signed; and, requests be signed or not signed, similarly. As we see above, "verification" is obligatatory for the unsigned-request/unsigned-metadata cases. If I replace the term verification with the term "OP/RP discovery", we have a situation much like in OpenID2, mapping identifiers/realms into endpoints. I'm wondering which infrastructure to use to distribute my SAML metadata (and possibly a Realtor's public FOAF data). One option is to put it in our application repository (RETS - an RDF like SPARQL server, that has a GETmetadata URI-bound transaction and that permits "community-extensions" to the (RETS) metadata schema). Another option is to put it in the XRDS/XRD, so XRI resolution can be shared when securing flows between SAML2 endpoints and also between OpenID endpoints. (I could even extend the RETS transaction model privately, to deliver XRDS documents!) Now, if I go with XRI as the data model, would I define an extension for the XRD schema, importing the SAML2 metadata schema say? If I do that, can this legitimately be done by private entities in the management model, or is this right reserved for an OASIS process?
[1] http://www.oasis-open.org/committees/download.php/22389/sstc-saml-profiles-errata-2.0-wd-05-diff.pdf [2] http://www.oasis-open.org/committees/download.php/17293 _________________________ 5 avril investement in OpenIDThe discussion of using openid for age enforcement got me thinking more widely.
It's interesting to see how quickly an authentication benefit (leave authenticated comments, suitable for building trust via endorsement) becomes attached to the issues of enforcement and control : (i) what's the assurance level of the assertion of age, nationality or other attributed fact, by provider, and (ii) how can one now enforce policy myXdesire based on that assured attribute. One can think more widely about the question of what focusing on mostly "control objectives" would mean for the investment prospects in relation to the budding vendor community, here.
The issues of enforcement and control are of course long embedded in the traditional outsourced identity management business - which already uses a myriad of proprietary and semi-standard protocols. Folks in that business will happily admit openid standards, I venture: they could not care less about which bits and bytes are used, so long a reasonable folk think its a reasonable thing to apply when addressing the customer's "control issue". Identity management is, and always will fundamentally be, an outsourcing revenue model, fitting neatly into Wall Street's "information service bureau' category.
The topics of control and enforcement always trigger question in my mind about the Foundation's mission. The mission comes across as wanting to above all promote authenticated comments on blogs, leading to the creation of a scalable trust framework in which linked-backed identity becomes an endorsing feedback system that ultimately self-regulates the average contributor - once reputation is publicly attached to the gestalt of his/her public contributions. Folk such as ClaimID have built clear demonstrators of such notions, building on "authentication via linkback services" to assert qualified ownership via openid and microIDs of posted authenticated _content_, too. (Having seen it all 'brought together as a concept" in ClaimID, I'm on board, as an eary adopter type!) However, I also see an undercurent in the Foundation's tone that seems to believe that -- even in the short term -- the only significant revenue that will ever be attached to all this, with which to sustain the infrastructure, will be good ol business of classical identity management outsourcing.
The most traditional identity management crowd (EDS, Hughes, Reuters, CAP, etc) competing for the (non-telco) $100M+ outsourcing size revenue opportunities will probably not directly participate in generating adoption of an openID-based trust feedback system: they are not evangelists, they are simple run of the mill business folk seeking to operate policy systems dealing with "control problems" . With luck, the business development folks in such companies may view OpenID as a market expansion driver however, for core services - leading to development investment or tech sponsorship. If the movement gets critical mass beyond the social networking space, one can see a world in which such firms, in order to build market share or get to market fast in the new market of authenticated comments and endorsement systems, will purchase those privately-held OPs that (a) somehow get critical mass of participation and consumer acceptance, or (b) have VC-quality Intellectual Property assets embodying some twist that make their approach particularly suitable or cost effective when applied to the very _traditional_ control and audit problems in banking, insurance, healthcare, suppy chain,..., and then - ultimately - general enterprise.
|
|
|