logout and misc Qs --shib idp

David Bantz dabantz at alaska.edu
Mon Nov 5 20:07:01 EST 2012

I'm going to over-state the arguments I encounter, I hope in service of 
clarity and unencumbered with qualifications:

On Mon, 5 Nov 2012, at 14:50 , Tom Scavo <trscavo at gmail.com> wrote:

> On Mon, Nov 5, 2012 at 6:41 PM, David Bantz <dabantz at alaska.edu> wrote:
>> It even contributes to the
>> continued conflation (in my local experience) of SSO with single set of credentials,
>> thereby implicitly legitimizing credential relay
> I'm not sure I understand either side of this argument. Can you
> elaborate a bit more?

It's been claimed many times here that we have "single sign on" because you
can use the same credentials to log in to multiple services.  That is, you 
relay the credentials to service A which checks to make sure they can spoof
you using the username and password provided to log into AD or LDAP.
When you go to service B, C,…, repeat the same process.

Thus when a new service comes along and says "oh yes, we can integrate
with your infrastructure - just have people give us their AD / LDAP credentials,
they mean of course "we'll authenticate them by using those credentials against 
your AD / LDAP, and if we can spoof them, we take that as authentication."
(They never add that this gives them not only users' credentials, but a set
of verified users' credentials.  If challenged, a typical response is to assert 
that credentials are not exposed because they use SSL and the credentials
are encrypted.  About half pause and realize the credentials will be available
unencrypted when I ask just how the service can use
encrypted credentials to authenticate a user.  Those then invariably claim,
in effect, that their software is immune to hacking and their systems admins
are incorruptible.)

When I attempt to offer trusted third party authN generally and Shibboleth
specifically as a better solution that does not expose users' credentials in this
way, I'm often met with puzzlement.  If I attempt to explain the difference,
I risk being called a zealot, and eventually told that the risk is acceptable
to the institution.  Should I respond that it may not be acceptable to the user
if they understood, I risk being called fanatic.

When I object that relaying credentials to many different services is not SSO, 
I am often flatly told that it is, and that I'm just quibbling or using rhetoric to 
argue for my preferred solution. 

In each of these unproductive arguments, the fact that users are repeatedly
asked for their credentials for (relay to) different services and been accustomed to 
this being labeled SSO makes better alternatives hard for some to grasp,
and easy for some to disparage as not significantly different from the easier
older approach they know.

>> their discomfort with lack of total control
>> implicit in trusted third party central authN

> If you supported AuthnContext at the IdP, and offered your SPs some
> options (such as two-factor authentication), would that make a
> difference?

What I mean by discomfort with lack of total control is a stance that,
as a service provider, I should manage and have direct control over
all aspects of providing access.  Trusted third party authN is outsourcing
a portion of that; it's out of my direct control and that's a problem for me.
Maybe because I don't trust those operating the authentication infrastructure,
but more likely just a desire to be in control and not dependent on an 
external service.  We have units that I estimate have spent thousands
of programmer-hours designing, building and maintaining their own in-house
authentication schemes and internal databases of users, even though
their applications demonstrably integrate readily with Shibb.  They're
not getting better data about users because we rely on the same ERP
for that data.  If these groups see an advantage to two-factor authN, I'm sure
they will want to choose, deploy, manage, and support a solution 
internally rather than rely on a central service.

> Tom

Hope that clarifies my concern.

David Bantz

More information about the users mailing list