Hi, Swithun -- On 04/04/2011 04:59 AM, Swithun Crowe wrote:
> Another example is that of chaining SSO authentication with the other > methods found in FeSL (user file, LDAP etc.). FeSL takes your credentials, > and then uses the methods specified in jaas.conf. Shibboleth requires that > you visit a special page where you enter your credentials. I'm not sure > whether it is possible for Fedora to take your username/password and > conduct the SSO authentication behind the scenes, and if successful, > replicate the HTTP headers and cookies, so that you stay signed on. Part of the goal of SSO systems like PubCookie and Shibboleth is to minimize traffic of credentials in requests: a user goes to a third-party host and enters their credentials there, with the communication between the browser and the authentication host encrypted over HTTPS. Once they authenticate, they receive a ticket in a cookie, and/or some HTTP headers, that applications can be configured to recognize and use to make authorization decisions. This way, applications never need to know the user's credentials; they just need to know where to forward the user to get authenticated, and they need to know what to look for in the returning user's request to determine if they've been authenticated, and make a decision about their level of authorization. Both Pubcookie and Shibboleth rely on the HTTP protocol, and the browser's ability to redirect a user from one host to another, to control this triangular transaction (user, authentication host, and destination web application). A filter could be written to somehow get user credentials from Fedora and forward them, but that would break the whole point of the SSO model -- remove handling of credentials from the destination applications. This same problem exists for Subversion, and other command-line applications: there's no way to redirect the user from one host to another and back again at the command line, the only workaround is to fake a user HTTP transaction on the web application host, which means the web application has to solicit the credentials from the user -- a big no-no. I think that's why you haven't seen any shibboleth+svn command line plugins, although it's clearly desired. I think your suggestion of chained authentication methods and filters would be the way to go. The two most common ways of interacting with Fedora are through a web interface (which can be protected by Shibboleth) and at the command line, which could be protected by an Xml user file, an ldap server, or any other credential store that's available locally and configurable in JAAS. Command line access is generally for management and administration, and as such, would usually be restricted to a small number of users; web access is more typical of the world at large, and lends itself better to SSO. I'm sure there are use cases that can turn the above scenarios on their head, but I wonder how common they are; and if they are compelling enough to deliberately break the SSO security model. -- Scott -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison pra...@wisc.edu ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
