Shibboleth Developers

[Peter Williams <>]

If I state a (signed) requirement of passwordprotectedtransport and 
force-authn=true, I expect the SSL endpoint in the IDP to perform a full SSL 
handshake. That handshake invokes the security service of peer-entity 
authentication (at layer 4), where I expect the IDP to insist it retains the 
SSL server role. If the SSL entities cannot newly agree an SSL ciphersuite 
that authenticates the SSL-client endpoint to the SSL-server endpoint (and 
then perform a positive handshake based on that ciphersuite), I expect a 
signed SAML response with an error status. I am NOT expecting https semantics 
to be enforced (where client certs are tied to users of "browsers" [or their 
proxies]).

Viewing cardspace as an authentication scheme to an IDP, are there any 
rumblings of folks publishing an authcontext declaration/urn for it? I can 
see our SP requiring a cardspace+ssl auth context be used, which implies 
assurance of (a) use of the trusted desktop SEF (security enforcing 
function), (b) the SEFs of certain TLS ciphersuites, and (c) SEF of 
constrained PKI model cardspace can superimpose on the https endpoints of 
IDPs.

Yes, I'm drawing rather technical distinctions between SSL/TLS and https - 
suited to a dev list. The obligation to use SSL in protected password 
delivery may be satisfied by an SSLVPN tunnel from a cisco secure desktop for 
windows, for example.

> -----Original Message-----
> From: Peter Schober 
> [mailto:]
> Sent: Thursday, February 26, 2009 8:09 AM
> To: 
> 
> Subject: Re: [Shib-Dev] Feedback for Shibboleth 2.2 roadmap
>
> * André Cruz 
> <>
>  [2009-02-26 14:50]:
> > On Feb 26, 2009, at 13:43 , Chad La Joie wrote:
> >> André Cruz wrote:
> >>> No. Most people think this means that the probability of the user
> >>> being
> >>> who he says he is is bigger.
> >>
> >> Really?  That's not what I've heard any app developer say.
> >
> > That's exactly what Peter Schober said:
> >
> > Peter Schober wrote:
> > "Some of our SPs were expecting to increase the likelihood that the
> > correct person is accessing their resource by using forceAuthn."
> >
> > At least that's the way I read it.
>
> Mostly, yes. I actually started out with a negative sentence, but
> restructured to make it simpler/easier (bad idea ;)
> Let me put it this way:
>
> Some of our SPs were expecting to decrease the likelihood of some
> unidentified person walking up to a PC (e.g. one of those locked-down
> kiosk PCs in parts of our own university, where you can't close the
> browser or delete cookies) and be able to reuse someone else's
> "leftover" SSO session. Very probably this will happen by mistake and
> does not require bad intent on part of the next person using that
> kiosk.
>
> Obviously those kiosks need to get fixed (to allow ending your
> session, clearing up all data), but in principle the same applies to
> other PCs, kiosks, etc. which we have even less influence.
>
> A button on the IdP login.jsp to disable the previous session handler
> for this one session might also help here, is that a feature request
> you would consider?
>
> cheers,
> -peter
>
> --
> 
>  - vienna university computer center
> Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
> Tel. +43-1-4277-14155, Fax. +43-1-4277-9140