On Mar 27, 2008, at 9:10 PM, Asa Hardcastle wrote: Hi Peter,
These are great offers. I need to think harder on how we can work together.
I am trying to set up the Sun Federation Manager on CentOS w/ the SAMLv2 plugin (and using the ECP filter as described in the OpenSSO docs) ... we shall see how I fare tomorrow hopefully ...
on practical step "b" you are correct, the ECP plugin receives the PAOS request from the SP. It then expects to negotiate with an IdP and eventually receive an AuthNResponse that it will then pass back to the SP. It is my understanding, and Peter Pritchard (ECP plugin developer who started this thread) should correct me, that the negotiation with the IdP is expected to involve some plain old html login page(s) which eventually result in a SOAP response.
The ECP<->IdP interaction is explicitly undefined ... but basically the IdP should eventually return an AuthnResponse ... either redirect, login page, etc (which sounds to me suspiciously like HTML, POST or Redirect Artifact Resolution) ...
Your trivial to deploy IdP does not support ECP, but you are saying that we could configure to do a non-ECP SAMLv2 authentication with the plugin?
I would hate to see the ECP plug-in spec muddy the specification ... but that being said ... I could pretty easily extend the plugin to allow each IdP to be configured in the plugin to use a 'legacy' negotiation mode (like the SSO/Browser profile for non-ECP compliant IdP's)(this may be more of a political issue) Or are you thinking you might be able to modify it to perform the IdP side of ECP?
This would be ideal obviously. Also, your last point about an IE plugin is a very good one. We'll look into fiddler.
I have already looked into building a Safari plugin (actually I think the common approach is to cheat by using the InputManager ... instead of using the Netscape Plugin API or the WebKit Plugin architecture ... Growl for instance uses this approach for integrating into iChat and other apps ... I think) talk soon,
asa -- Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib Tel: +1.413.429.1044 Skype: subsystem7
On Mar 27, 2008, at 12:25 PM, Peter Williams wrote: I can offer 2 things to any experimenting party:- 1. An OpenID IDP that is fully "consistent" with the precepts of the OpenID movement. The "OP" delegates to a SAML2 SP (and thence an IDP via SAML2's IDP proxying). This works in much the same way that Microsoft .NET reference code from a OpenID leading evangelist firm delegates to Microsoft ASP.NET's "form-based URL-cookie" mechanisms - to invoke local authentication and "AuthMan" role based authorization. Any claims that its fundamentally inappropriate to delegate to SAML2 for authN and authZ handling will be robustly rejected, on the grounds that the process is equivalent to reference code. 2. A well-deployed SAML2 server cluster that supports the SAML binding, but not the PAOS binding. My SAML2 server vendor refuses to release practical data about leveraging the product's actual support for the PAOS binding, even though the product release passed certification in PAOS. I can thus offer that we leverage the SAML binding to the IDP only, for experimentation -- or you can help me further lean on the vendor, so we can apply PAOS when communicating with SPs. Do either of these offers help? If I think practically, now :- a. I should refocus - getting a first trial of my SAML2 SP to show interworking with the Shib IDP. b. You would seem to have a browser plug-in using PAOS to talk to a PAOS-capable SAML endpoint on the SP channel, and I have a trivial-to-deploy SAML2 IDP that can use the SAML binding to talk to that plug-in - acting as a binding bridge. c. I am able to have my IDP simulate "IDP-proxying", relaying control on to the Shib SAML2 IDP c. Whichever flow actually works in your browser plug-in for FF should be repeatable in IE, using scripting in the "fiddler" proxy (the "universal" plug-in to IE, for developers). Better still, I have an easy-to script RDF "data" server that can perform "bridging", showcasing that ECP and PAOS is not limited to browsers.
The FF/ECP logic is very simple and is essentially a proxy with basic XML parsing & message verification features (and short-term caching to allow for non-immediate IdP responses)
From: Peter Williams
Sent: Thu 3/27/2008 6:53 AM
To:
Subject: RE: ECP Profile compliance for Shibboleth 2.0
-----Original Message-----
From: Asa Hardcastle <>
Sent: Thursday, March 27, 2008 5:50 AM
To: <>
Subject: Re: ECP Profile compliance for Shibboleth 2.0
IIW is a good opportunity to show that SAML2 is a powerful force in
SSO and beyond. OpenID will be everywhere. Cardspace will be all
over it (maybe). I'd like us to have a killer demo, but I can't do it
alone.
Here is a brief description of what I'd like to show at IIW.
COMPONENTS:
ECP Firefox Plugin
SAML2 SP - a photo sharing site or something fun (based on ZXID)
ID-WSF 2.0 Client Bindings (Based on OpenLiberty)
SAML2 IdP (would be nice if this could be both Shib and Symlabs)
OpenID IdP (who knows from where)
ID-WSF WSP, Discovery, People Service, Personal Profile (Symlabs)
DEMO:
* ECP login, selecting an IdP
* ID-WSF Disco EPR sent through the SAML2 Assertion (automatic in
Symlabs, requires glue in Shib, but since OpenLiberty is written using
OpenSAML code, should be easy to create a mechanism to pull an EPR
from symlabs ID-WSF and place it in the Shib response )
* photo sharing application (sp) uses people service to manage
identities and sharing and profile.
* sp can share access (private, non-trivial) through ID-WSF.
* share access with OpenID users (would be nice to demonstrate the
differences in privacy, ease of use, security, etc. One primary
difference would be the inability to bootstrap into ID-WSF)
* allow for an OpenID user to "upgrade" into the SAML2/ID-WSF
environment, obtaining an ID.
There is a lot to do here. The missing pieces from Shibboleth IdP are:
>> ECP Support (honoring PAOS AuthnRequest, sending a login panel or
whatever, upon success sending a AuthNResponse) - PJ is willing to
help, but it seems like this would be a relatively simple thing to add
by someone who knows the code well.
>> ID-WSF Support - a simple start could be simply making a query
through a SOAP channel upon SSO to obtain - given the location in the
code where this insertion might occur, I could add this code.
In the future it would be nice to model an ECP authentication
procedure that could all happen behind the scenes (through an ECP
plugin). Basically it would be 100% SOAP/XML, login would be like
magic. We could then present this method to Liberty for inclusion in
a future ECP specification.
thanks,
asa
--
Asa Hardcastle, Technical Lead, openLiberty ID-WSF ClientLib
Tel: +1.413.429.1044 Skype: subsystem7
On Mar 25, 2008, at 4:37 PM, Peter Pritchard wrote:
> Hey all,
>
> Just wanted to drop a line into the mailing list, that I am
> investigating adding support within Shib 2.0 IdP for the SAML 2.0/
> ECP Profile.
>
> I have built a Firefox plugin, which claims to be ECP-compliant ...
> but need to show interoperability with IdP's of all flavors.
>
> My co-worker, Asa, technical lead of the OpenLiberty ID-WSF client
> library, is hoping to do a demo at the IIW this May. It would be
> nice if we could show Shib2 IdP bootstrapping an SP into an ID-WSF
> environment using the ECP Firefox Plugin.
>
> If anyone has anything to throw into the ring, I'd certainly
> appreciate any comments, suggestions or assistance.
>
> - Peter Pritchard
>
|
