Shibboleth Developers

[Peter Williams <>]

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

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

If I guess the thinking, the SAML format is regarded now where the X>509 
format is, after 20 years of use. Its just a blob, into which you stuff 
fields. Any old fields. Just like in X.509, where any old crap gets thrust 
into the cert extensions, with little consideration of schema, security 
model, etc.. Anyone with openssl is now CA, certified to produce drivel.

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

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). I don't 
assume that the ws-fedp implemented by ADFS v2 is the same produced by a 
best-practices IDP, when created using  the (latest) WIF library. They are 
SUPERFICIALLY similar, except the later stuff has more security concepts 
built in. Typically, one learns what they are 12-18 months after library 
release (just a windows community way of working), after its all settled 
down, had a service pack applied to two... and good ideas may have had to 
fall by the wayside, when the adopting  community rejects them!

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. My temptation to 
leverage its ws-fedp engine to talk to ACS is not going to be a happy 
interaction. That ACS interactions are not the semantics of authnReq protocol 
is well understood. Its something different - and I don't even actually know 
what it is yet, except that it's an exploration of the world related to pork 
(pun).




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

 
[mailto:]
 On Behalf Of Cantor, Scott E.
Sent: Friday, June 24, 2011 11:22 AM
To: 

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

On 6/24/11 1:50 PM, "Peter Williams" 
<>
 wrote:

>Why such scorn? The issue with ACS v2 is obviously about some trivial 
>fixes, based on learning what happens when deploying the technology you 
>have been all working on for decade now to 1,000,000 sites run by your 
>typical, self-taught-computing, vb programmer (vs a 100 universities, 
>with scholar-grade education levels and funding).

Because the missing AuthnStatement is what makes it scale? I don't think so...

>Of course, it doesn't actually work... but that is (at it stands, 
>before someone deploys a debugger for an hour) because (a) PingFed in 
>SP-role needs to be happy to receive a SAML-format assertion over 
>ws-fedp that omits an AuthenticationStatement (just as WIF-build SP are 
>evidently
>happy)

Do you really not see anything wrong with this?

>Now, how well does Shib *fit* into this bridging world in light of the 
>fact that SPs (RP sites fronted by SP protocol interfaces on per-RP
>endpoints) are going multi-tenant... is my real issue set?

I have essentially no idea what you mean, becaue the words you throw around 
have no concrete meaning to me. I assumed you meant a single SP handling 
vhosts for different customers, and I answered that as best I could. I doubt 
most would find it reasonable because it's one process.

Otherwise I really have no idea what you're talking about.

> I'm assuming (from context) that really it doesn't, given the 
>architects' scorn for very concepts involved.

Because there are no concepts, just buzzwords. But no, I won't apologize for 
believing that the Internet should be end to end.

>Yes, it's all a bit of a "ham sandwich" of a design - in the sense that 
>the SAML profiles are fungible, in ACS-land. But, that's the nature of 
>the generic types in the SAML/OASIA standard, surely.

No, it's not. You have to write profiles, and that's what you implement to. 
The generic nature is what allows one to write the profiles. Skipping that 
step is how you avoid interop.

>Ok. Im starting to convince myself that I need to be negative on Shib
>(embedded) for Joomla. I'm just asking for trouble. Might as well stick 
>with the php script, based on simpleSAML, that translates one
>(unsigned/unencrypted) blob into another, once communicated over https. 
>I was hoping the Shib integration would "showcase" multi-tenancy, 
>provisioning on the fly, entitlement mapping, etc. But, I don't it's 
>going to; or at least not in a joomla integration.

I literally *cannot* answer your question. There is nothing concrete to 
answer. What I can say is what profiles we support, I can say that it's 
pluggable for supporting other profiles, and I can say that IMHO bringing 
bridging into the conversation is a red herring.

But your opinion that tweaking the requirements of the profile is a matter of 
obvious utility is simply wrong IMHO.

-- Scott