On 12/11/2012 05:32 PM, Amos Jeffries wrote: > On 12.12.2012 11:33, Trever L. Adams wrote: >> Hello Everyone, >> >> I am looking at Shibboleth. I have seen one example >> >> (http://www.switch.ch/aai/support/presentations/opcom-201105/AAI-OpCom-AAI_for_mandatory_authentication_and_proxy_usage.pdf) >> >> for using it with Squid. I am afraid it makes no sense to me. >> >> I am afraid I do not know much about Shibboleth yet. It has three >> components for authentication, user, password, domain. It has to use >> redirects, etc. >> >> I see an easy way for this to work, but need help figuring it out. >> >> If a user isn't authenticated, I need to send them to a url. > > > acl bounce src all > acl auth proxy_auth REQUIRED > deny_info 307:http://example.com/ bounce > http_access deny !auth bounce > > ... but see below... > >> >> How do I know if a user is authenticated? Well, it seems that this is >> going to have to be passing the requesting client's ip address to a >> program and get the response back if they are authenticated or not. > > NOTE: user != IP address. Therefore user authentication doe not imply > IP address is authenticated, particularly in HTTP where one client (IP > address) can be presenting traffic from multiple users. > Essentially stateful connection-based authentication and stateless > HTTP do not mix well - as is constantly being 'discovered' by NTLM > people. Yes, I had this reservation, but I need to figure out something. This is a private proxy to general Internet, so some fudging for the time being may be ok. > > >> It >> would be nice if I could pass a user name, but I am not sure how to do >> this as this would require interaction with the browser and this should >> be SSO. > > The ACLs above pass the Proxy-Authenticate header to a helper program > for authentication tests. That header contains username and security > token, sometimes domain if the auth type uses domains. > > SSO is a property of the *backend* accepting the credentials supplied > by the client to Squid. SSO is simply the process of the backend > accepting the same credentials from multiple services (Squid being one). > It is no more different than a user signing up at two separate > websites with identical username/password details and being able to > login to both. The problem with Shibboleth is it is SAML and requires a domain that is plain text (select from a drop down dialog). Hence the need to redirect to a webpage to select and enter things. RFC 6128 (is that right? the http auth stuff?) doesn't seem to allow a webpage to give credentials to be used for the next page. I do not know even if it does, if it would work for proxy auth. I suppose it might be possible to have them enter a bogus password and their full home user name (user@xxxxxxxxxxx) which seems to be returned by Shibboleth authentication. The problem then is, I need a secure way of sharing the data between the proxy_auth stuff and the page where they get redirected so that the two can be linked in a common database. Is there a way to do this? > >> >> If no, then do a url_rewrite_access (I am assuming this is correct)? > > redirector helper is one way to do it. But these must first accept the > request for processing (http_access allow). It is more efficient to do > the above ACLs I listed and alter the denial message sent by Squid > into a 307 redirect message. > > ** redirectors like external ACL helpers, do not perform HTTP > authentication. Just authorization. Can you show me an example of a redirector? (If I am just missing one in the docs, a url is fantastic) I think a redirector is how the url I posted did things, but I couldn't figure it out. > >> >> Finally, is it possible to have multiple authentication algorithms? > > When using Proxy-Authenticate: yes of course. But not with redirector? > >> Some >> of the users will be local and be able to do krb5/spnego. So, if at all >> possible, I would like to have the option of trying krb5, then spnego, >> then Shibboleth. > > I suggest you work along the lines of using an external_acl_type > helper for Shibboleth. Since it is more about authorization of a > request to be processed than authenticating that the source IP is a > genuine user account. > > > You can use localnet ACL or a similar check for internal/external > clients to skip or require the authentication with Negotiate/kerberos. > > > Amos Well, this is on a home network where various filtering would be required for different users (think of that for homes where parents think porn is ok for them but bad for children, or more likely that certain health or other categories are appropriate/needed by certain people, but inappropriate for young children, etc.) Thank you for the help, Trever
Attachment:
signature.asc
Description: OpenPGP digital signature
