Profil de PeterPeter's ruminationsPhotosBlogListesPlus Outils Aide

Blog


27 avril

Shibboleth2 ECP for IIS7/Windows 2008

To 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.
            const char* getQueryString() const {
                  return (char*)handlervar;                        // implement using nasty hack, for use by CGIReader
                  //   throw IOException("getQueryString not implemented");  // comment away not implemented throw
            }

2. in isapi src, comment out any undesirable, "non protocol" features

    g_Config->setFeatures(
        SPConfig::Listener |
       // SPConfig::Caching |                //disable caching support in library
        SPConfig::RequestMapping |
        SPConfig::InProcess |
        SPConfig::Logging |
        SPConfig::Handlers
        );

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
   PAOS: ver="urn:liberty:paos:2003-08” ; "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

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!

GET /Shibboleth.sso/TestShib?applicationId=default&providerId=none HTTP/1.1
Accept-Language: en-us,en-securid
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 3.5.21022)
Connection: Keep-Alive
Host: win8pw.rapattoni.local
Accept: text/html; application/vnd.paos+xml
PAOS: ver="urn:liberty:paos:2003-08" ; "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, private
Pragma: no-cache
Content-Type: application/vnd.paos+xml
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Sat, 26 Apr 2008 22:30:38 GMT
Connection: close
Content-Length: 1515

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Header><paos:Request xmlns:paos="urn:liberty:paos:2003-08" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1" responseConsumerURL="http://win8pw.rapattoni.local/Shibboleth.sso/SAML2/ECP" service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"/><ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" IsPassive="0" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://win8pw.rapattoni.local/shibboleth-sp</saml:Issuer><samlp:IDPList xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><samlp:IDPEntry ProviderID="none"/></samlp:IDPList></ecp:Request><ecp:RelayState xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1"/></S:Header><S:Body><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://win8pw.rapattoni.local/Shibboleth.sso/SAML2/ECP" ID="_f5c9b87a8863ad2f94c7be25b5522cc3" IssueInstant="2008-04-26T22:30:38Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://win8pw.rapattoni.local/shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/><samlp:Scoping><samlp:IDPList><samlp:IDPEntry ProviderID="none"/></samlp:IDPList></samlp:Scoping></samlp:AuthnRequest></S:Body></S:Envelope>

_________________________
Peter Williams
Chief Information Security Officer
Mobile (805) 416-6305


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 Firefox

Using 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:-

Windows does not have a shell to build .sh file scripts, or a zip command. Perhaps, only Eclipse tools (or tool extensions) should be used to build the project to maintain build portability.

I had almost no modern personal context on any of the browser/toolchain, but followed steps 1-4 quite easily

Eclipse 3.2 for Java/EE

Web Tools latest

XUL tool chain latest

SVN src control plugin.

To practice a little with Firefox (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14) and get a basic orientation, I installed the "sxipper" commercial-grade plugin, learning to install/use it on an openid site (where it did fine).

Step 5 was a little more difficult, given I have no recent context in Eclipse or its whole UI concept for the IDE. I did use the IBM JCOP Eclipse for building javacard firmware 3 years ago, and thus half-figured/half-remembered XUL project making/running out, by analogy. I think I figured things out to about 90% completion; but build documentation was just lacking (for a complete novice in this highly technical toolchain).

Step 6 is confusing. I created a txt file (I called it "foo.txt") in C:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\81ecn5k5.default. There is no subdirectory there called plugins, note well - taking a hint from the wiki notes.

In the .txt file, I typed one line - a DOS file path to my eclipse workspace/sub-directory wherein lie various files - exactly as checkedout from the SVN repository. The line is "C:\Users\Administrator\workspace\saml2_ecp@openliberty.org", at which directory there are several files, including saml2_ecp@openliberty.org.xpi - No local build has completed (lacking sh(1) and zip(1) - or alternative instructions)

I do note that the src file :install.rdf" (that updated_package.sh would zip up into the xpi file along with other resources) has a {GUID} in its ID field. This seems to counter the counsel of the wiki that seems to want the GUID replaced by the string saml2_ecp@openliberty.org.

Selecting the extension project root, and Launching the Firefox Launcher does launch Firefox, and allows selection of the default profile. Its not clear the extension is being loaded however, and no ECP add-on appears in the list of add-ons, under Tools.

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.

_________________________
Peter Williams
Chief Information Security Officer
Mobile (805) 416-6305

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.

_________________________
Peter Williams


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 schema

Looking 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]

"Note that if the <AuthnRequest> is not authenticated and/or integrity protected, the information in it MUST NOT be trusted except as advisory. Whether the request is signed or not, the identity provider MUST ensure that any <AssertionConsumerServiceURL> or <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack."

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?

The elements in the XRD schema are intended for generic resource description, including the metadata necessary for XRI resolution. [2]

An XRDS document is intended to serve exclusively as an XML container document for XML schemas from other XML namespaces. Therefore it has only a single root element xrds:XRDS in its own XML namespace identified by the XRI xri://$xrds. [2]

It also has a single attribute, xrds:XRDS/@xrds:ref of type anyURI that identifies the resource described by the XRDS document. The formal XML schema definition of an XRDS document is provided in Appendix A. [2]

[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

_________________________
Peter Williams

5 avril

investement in OpenID

The 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.