enabling user specificed .htaccess files with Shibboleth

Russell J Yount rjy at cmu.edu
Thu Aug 2 09:34:57 EDT 2012

Primarily I am concerned about scenario:

  User accesses a page which requires an authenticated user from IDP A and so authenticates to IDP A to get in
  User attempts to access a page which requires authenticated user from IDP B

The user cannot access it since they have a credential from IDP A already and Shibboleth does not seem to support changing which authenticated user they are even if user can login to IDP B.

I could see this confusing people, but it may be a minor issues since most people would not have logins on multiple IDPs.

My secondary concern is only backward compatibility in the short term.  Re-educating users that "require valid-user" is any user with InCommon may take some time to get everyone on board.


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Thursday, August 02, 2012 9:10 AM
To: users at shibboleth.net
Subject: Re: enabling user specificed .htaccess files with Shibboleth

* Russell J Yount <rjy at cmu.edu> [2012-08-02 14:13]:
> We have an Apache web server that serves user web pages as 
> http://servername/~username and  permits users to use .htaccess files 
> to protect content using Pubcookie.  We are now examining issues of 
> using Shibboleth for authentication rather than Pubcookie.
> Has anyone else use Shibboleth for this type of service and can offer 
> suggestion as to configuration?

We've been doing that for quite some time. Nothing special as far as the Shibboleth SP is concerned. An .htaccess file (or thousands of
them) is just an .htaccess file.

> With Shibboleth one can place directives such as ShibRequestSetting 
> entityId https://SOME-IDP-ENTITY-ID ShibRequestSetting requireSession 
> 1 to specify the IDP to use for authentication. This however only has 
> an effect if the web user is not already authenticated.
> Is there a way to force shibboleth to authenticate to the specified 
> IDP if the user is not already authenticated through that IDP?

The IdP users are from is commonly only considered as part of authorization (e.g. require affiliation ~ ^(student|faculty)@example\.edu$ ) where IdP selection is not restricted, but authZ rules ensure only users from specific IDPs will be able to access the resource (as other IdPs are prevented from issuing those scoped affiliations by means of the shibmd:Scope extension and the SP's attribute-policy.xml.
Note that with the 2.5 SP you could also require an IdP's entityId.)

But since any "require" directives would be under control of the same entity potentially setting specific ShibRequestSetting I probably just don't understand the use case at hand.
Why would you want the SP/webserver to know other IdPs but not let users create a session with one of them? Sounds like maybe you'd want to split off those accounts to a system which only knows your IdP.

> Is there a way to turn off this capability?
> Is there a way to restrict which IDP's a user may specify? (Without 
> removing the other IDPs from the SPs metadata of course.)

You're asking for a way to centrally disable specifiying the entityId content setting within .htaccess files -- but allow its use elsewhere (e.g. as part of a HTTP request to the Login handler)?
I don't think that's possible and I doubt this will achive much.

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

More information about the users mailing list