Shibboleth Developers

[Peter Williams <>]

Ok. We can say things academically now: Shib has not implemented the ACS 
profile, which is a variant of the ADFSv2 profile, all of which are variants 
of (profile of) ws-fedp specification's standard types.

Oh, and neither has PingFederate.latest. And that's annoying, since it 
claimed to have become "compatible" with WIF (the library that implies the 
various ACS and other profiles, not that anyone outside Microsoft apparently 
knows what they are).

So the right question for the "shoomla" (shib+joomla) product vendor is: did 
you augment open source Shib with an ACS-specific profile that tunes the SP 
for the way in which ACS v2 uses OASIS saml standard types.

I doubt Ill get a response, to that. But I'll try!

If the answer is yes, its worth $1500 as its cost me way more than that to 
merely understand the issue. $1500 is basically 10 hours of programming (or 6 
hours at US defense contract rates). I doubt I could produce an ACS profile 
in Shib in 10 hours, and at reasonable QA. After 2h on Microsoft forums, I 
cannot even figure how to make an AuthenticationStatement.

I do think that those making WIF SPs (hand built using SP libraries) are 
getting somewhat "deceived" by ACS if they assume Yahoo and Google have 
"authenticated" the assertion upon which they then rely, to grant access. A 
name-game is going on, since in reality the ACS is only "relaying" what, in 
google or yahoo-land, might have been considered authentication statements by 
the originator but which ACS only FORMALLY denotes as "attribute" statements.

But its all good in the long run. The cloud is changing the SSO delivery form 
and the SSO semantics, somewhat. I don't expect the notarized signature in 
Maryland to have exactly the same semantic as found ins similar documents in 
California, and be even less like similar docs used in Spain/Mexico/Peru - 
with their more latin legal traditions. At the same time, it all forms a 
national/transnational norm that gets the job done - at universal scale. So 
it is with signed assertions in SSO land, now we are talking about 
national/international infrastructure.

Put another way... its better than PKI.







-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Cantor, Scott E.
Sent: Friday, June 24, 2011 12:21 PM
To: 

Subject: Re: [Shib-Dev] how good is the Shib SP ws-fedp support?

On 6/24/11 3:10 PM, "Peter Williams" 
<>
 wrote:

>Is there anything wrong with minting an SAML token with no 
>AuthenticationStatement?

If you're attempting to claim conformance to a profile that requires one, 
yes. If you're not claiming that, then no.

>No there is not. Obviously, it doesn't have the token doesn't have the 
>semantics of the AuthnRequest protocol (in SAML2 spec).

It doesn't meet the requirements of the SSO *profile*.  We implement 
profiles. If you need a new profile, that's usually going to be new code.
It may well be very little new code.

>Now, when interworking using SAML2 protocol , the thinking is probably 
>different. Now, enforce the semantics of authnReq protocol. A different 
>level of rigour.

That's all I'm saying.

>I suspect they are trying to DISTINGUISH the saml2 flows from ws-fedp 
>flows, each having different security models - where the SAML2 flow 
>come with a certain relationship model between agents. And, knowing 
>MSFT, there are different generations of ws-fedp (since its already a 
>decade old).

Your attempt to paint this as anything but arbitrary laziness on the part of 
whoever wrote the code is not persuasive to me. You ascribe design where I 
think there is simply domain ignorance and lack of attention to detail.

>Anyways, getting way off topic. Shib obviously ain't going here. I 
>think my final conclusion is: use Shib2 for  SAML2, and that's it.

If you don't want to write code to implement the custom thing you want to do, 
that's correct. What is, I think, a mistake, is believing that anything else 
will be much better. You can't interoperate without a profile.

Our position on shipping new profiles is simply that they should be 
formalized and be something that materially helps deployers. Your case may be 
the latter, but that's not the only consideration.

Would it be cool to have a scriptable profile that lets somebody customize it 
easily from outside? Sure. I don't have that.

And I f what you want is something that can be tweaked using PHP code, it 
stands to reason that a PHP implementation would be more amenable to that.

-- Scott