[Shib-Users] End user security across applications

[ssha...@uoregon.edu]

Hi,

My institution is bringing Shibboleth in, and our department is trying to determine if it is appropriate for us to incorporate our web based application into it. Beyond viewing the introductory demo and browsing several dozen pages of material on the Shibboleth web site (Most of which was in jargon not familiar to me), I have no experience with Shibboleth.

My question concerns user security: A user logs into an Shibboleth enabled application and then leaves their workstation (with the browser active) unattended and unlocked.

If somebody else takes control of the workstation at that point, what is involved in them locating the other secure systems the user has access to and 'visiting' them?

I'm interested in how others are handling this potential problem. I realize that this is mostly a social/policy issue, and that most of us have policies in place that discourage this sort of behavior. I also realize that some, if not many, of our users don't know we have policies and often forget some of the basics that IT professionals often take for granted.

As I've read through the Shibboleth documentation, I see references to the "Previous Session" login handler of IdPUAuthn. Is that an option - asking the user to re-enter their password as they are about to access our application or perform an action within our application that requires them to be who they say they are (to the best of our ability)?

Thank you,

Steve Shapiro
Office of Research Services and Administration
University of Oregon

[Scott Cantor]

> If somebody else takes control of the workstation at that point, what is
> involved in them locating the other secure systems the user has access to
> and 'visiting' them?

There's no inactivity timeout at the IdP in SAML, and SSO is really up to
the deployment. You can have none at all, but once you have any SSO
happening, you lose most of that control at least for the duration of that
session.

> I'm interested in how others are handling this potential problem. I
realize
> that this is mostly a social/policy issue, and that most of us have
policies
> in place that discourage this sort of behavior. I also realize that some,
if
> not many, of our users don't know we have policies and often forget some
of
> the basics that IT professionals often take for granted.

If the user values their credential, they'll take care of it, and if they
don't, nothing you do will prevent them from giving it away. It's also about
accountability. If there is none, or if it's an externality to the user,
there is no hope. We can play technology games all we like, but there is no
chance of winning that battle.

> As I've read through the Shibboleth documentation, I see references to the
> "Previous Session" login handler of IdPUAuthn. Is that an option - asking
> the user to re-enter their password as they are about to access our
> application or perform an action within our application that requires them
> to be who they say they are (to the best of our ability)?

That depends on the level of granularity you mean. You can limit SSO in some
ways at the IdP, but it's also up to SPs to demand it via ForceAuthn,
possibly by isolating critical resources such that an explicit ForceAuthn
session is requested, and then checking the time of authentication (which
most apps will not do). And of course, you can't get ForceAuthn without SAML
2, so it all depends on the deployment.

I don't think that the IdP can by itself bypass SSO based on the SP making
the request, but I could be wrong about that. I think it would take a custom
login handler. Of course, if authentication is handled by something outside
the IdP, it could be rigged to do that.

-- Scott

[Peter Williams]

We have sp apps who poll the idp, checking the member is still in good standing. It exploits the saml procedure of asking for an (new) assertion, but don't interrupt the idp ui to get it. They generally do this before committing a major transaction in the sp infrmation system. This seems simple enough to do.

This is the kind of area where I have to admit I waiver when it comes to the detials - for correct saml behaviour. Should the second assertion be citing an authcontext that indicates its reusing the current session (vs challenging a user for strong auth over a new ssl handshake)? Should an authmethod url in the "existingsession" auth context be pointing to the specific "auth method" used (eg timestamped-url to the members record, whose standing is currently checked as "still good")?

[Scott Cantor]

> This is the kind of area where I have to admit I waiver when it comes to
the
> detials - for correct saml behaviour. Should the second assertion be
citing
> an authcontext that indicates its reusing the current session (vs
> challenging a user for strong auth over a new ssl handshake)?

I believe this was all covered on saml-dev a while ago. The consensus was
that it's up to you, but AuthnInstant should be accurate. If you don't use
PreviousSession, don't update the timestamp.

Which is the point...the apps would have to care enough to check all of
that. The vast majority won't.

Furthermore, this doesn't prevent the attack in question. If you do SSO,
there's a session at the IdP and during that session, you're vulnerable.
Nothing the SP does will change that, short of using ForceAuthn and checking
AuthnInstant. Either you bypass SSO or you're vulnerable.

-- Scott

[Shapiro, Steve]

Thank you all for your replys.

I'm wondering if there is a glossary of terms on the Shibboleth web site
that can help me understand what all the abbreviations and proprietary
terms mean?

Steve Shapiro
University of Oregon

[Ann West]

Steve,

I can help you with the terms and such. I'll send you a note off the list.

Ann

Ann West
Tech Transfer and Outreach
Internet2

[Scott Cantor]

> > I'm wondering if there is a glossary of terms on the Shibboleth web site
> > that can help me understand what all the abbreviations and proprietary
> > terms mean?

There's also a SAML glossary, though I don't know how useful it is.

http://www.oasis-open.org/committees/download.php/21111

-- Scott

[Peter Schober]

* Shapiro, Steve <ssha...@uoregon.edu> [2008-09-24 21:19]:

> I'm wondering if there is a glossary of terms on the Shibboleth web site
> that can help me understand what all the abbreviations and proprietary
> terms mean?

Not on the Shibboleth web site, but SWITCH and TERENA each have one:
http://www.switch.ch/fr/aai/about/glossary/
http://www.terena.nl/activities/tf-aace/Del/B.2/AAITerminology1_0.pdf
(both are in english language)

Cheers,
-peter

--
peter....@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2008-09-25 15:10]:
> http://www.switch.ch/fr/aai/about/glossary/

don't know how I ended up on that URL but make that
http://www.switch.ch/en/aai/about/glossary/
^^
in case they ever decice to actually list french explanations on the
french site (instead of the current fallback on english).
-peter