ACL-based secure search without user authentication

[Matt Snyder]

Hi all... I'm working on a project with a client who has these basic
things:
* Database of URLs and corresponding ACLs
* Microsoft-based portal with SSO
* Active Directory

I understand that the steps for creating secure search with GSA are
these:
1. import the content with a URL feed
2. import the ACLs through security SPI
3. configure LDAP connection to get users and groups from Active
Directory
4. Create a SAML bridge between the GSA and the portal SSO for
authentication

I have a question about number 4: the client is planning to have a
custom search app that sits between the user and the GSA, and the
search app will take care of the user login with the SSO. Is there a
way to send the user's credentials to the GSA, without the GSA having
to authenticate the user again with the SSO server?

-Matt

[Michael Cizmar]

Yes. The search service of the GSA is designed to interact directly
with the GSA. I've published the steps to do this here:

http://www.mcplusa.com/blog/2009/06/remotely-calling-the-google-search-appliance-restful-web-services-when-saml-is-enabled/

Basically you pass through the cookies to the GSA and handle the
cookie redirects.

Michael Cizmar | MC+A
Google Enterprise Partner
http://shop.mcplusa.com | twitter: http://www.twitter.com/mcplusa

[Matt Snyder]

Thanks Michael. In your scenario, the GSA is connected to the SSO
server via SAML? Is there a way to do this without SAML, i.e. without
the GSA needing to talk to the SSO server?

[JMarkham]

Hi Matt,

So, it sounds like you're planning two different mechanisms for
authentication: 1) LDAP and ACLs (also known as Early Binding), 2)
SSO integration (also known as Late Binding).

To the best of my knowledge, you only need one auth mechanism, unless
of course, the LDAP way isn't working for you for some reason.

Yes, you can connect to SSO without SAML, provided your SSO
communicates authenticated sessions with cookies. If so, you only
need the SSO login setup in Crawl and Index > Forms Authentication,
then in Serving > Forms Authentication you need a Sample URL for the
appliance to use to get itself authenticated and to verify incoming
authenticated sessions. This will always happen at the GSA, and this
is what you want to have happen, because the GSA will then only send
back the results that the authenticated user is authorized to see.

However, if you have LDAP available, along with a database of ACLs,
then I don't believe you need any SSO integration at all. Again, I
don't know your particular issues and sequence of events that led you
to where you are. :)

Now, I haven't implemented the LDAP way, because our particular
architecture would make the ACL route too complicated, so I don't know
that I can advise you there. I can certainly adivse uses of SSO
integrations, however.

Jeff

[Matt Snyder]

Thanks, Jeff. My most basic question is: can the GSA do authz without
doing authn. In other words, if I load the GSA with ACLs and users
and groups through the policy SPI, then can I tell the GSA (through a
cookie or url parameter) the name of the user, and have it do secure
search, without any authentication? This would be very weak security,
since the cookie could easily be spoofed, but the GSA is talking only
to a front end server, not to users directly.

[JMarkham]

Specifically, as far as doing authz without authn, the answer is no.
You need authn first, so the GSA has the appropriate, verified (I
stress that verified piece) credentials with which to do authz. These
two functions are not capable of being separated.

So, I've been curious about the use of ACLs myself, so I thought I'd
do a bit more reading. I'm following the Help link on the LDAP Setup
page under Administration in the Admin Console, then following other
documentation links from there. Everything I'm reading says that the
use of LDAP (and hence ACLs) requires a login (read: entry of userid
and password) when the user "hits" the appliance. This tells me that
ACLs won't work with an up-front authentication process. This also
tells me that you won't get the appropriate LDAP object references
from SSO integration either, to try to use those to verify against the
ACLs.

I'm betting that you'll want to employ only the SSO integrations,
without the LDAP piece. In this way, you can have the users
authenticate (read: entry of userid and password), separately, let's
say upon entering your portal or main web site. Then, the SSO
credentials (hopefully in cookie form) will pass to the GSA, which
will do a quick authn verification so that the GSA has a verified
session to work with. Then, as results are being returned, those
cookie credentials are sent to your content servers to request a zero
byte range of content (header: "Range: bytes=0-0") to verify the
user's access to that piece of content. If you're thinking this is
weak security, it isn't. I've known how to hack for years, so I
always test out security schemes when I'm involved in implementing
them. I have been absolutely unable to spoof or otherwise fool this
security scheme at all, due to that verification piece I mentioned
earlier. :)

One more option, depending on the granuality of authorizations to your
content, is to mark all your content public, so the GSA doesn't
require authn or authz, and allow your front end page/system to do
that for the GSA. If you have any authorization granularity at all
(read: access is maintained for individual pages, collections of
pages, or sites), this solution won't work.

Not a solid answer, but hope that helps.

Jeff

[Matt Snyder]

Excellent answer, thanks Jeff! Confirms what I had thought.

[Michael Cizmar]

SAML is what is a little more tricky (and less documented). Without
SAML, you can simple forward the credetials that the GSA will accept
(i.e. add cookie to header). We've done it for SAML, Basic Auth and
SSO. All are some form of what is in that posting.

Michael Cizmar | MC+A
Google Enterprise Partner
http://shop.mcplusa.com | twitter: http://www.twitter.com/mcplusa

[Matt Snyder]

After some testing, here's what seems to be happening

In the test:
1. LDAP is not configured on the GSA
2. No external AUTHN provider is configured
3. secure content is crawled successfully using simple crawler access
rules
4. I manually added some ACLs for user testuser

On the search page, I select Public and Secure and do a search. The
GSA comes back with a 401 login, and I give testuser and a random
password. GSA accepts this, without doing any authentication (it
cannot, since no authentication method is configured). The GSA
correctly applies the ACLs and returns the appropriate results.

In other words, it seems like I can get exactly what I wanted, by just
not configuring LDAP or SAML. In my application, the front end will
provide the user name and bogus password to the GSA as a base64-
encoded attachment to the GET

[Matt Snyder]

Oops, I misinterpreted the behavior. What is actually happening is
that the GSA is doing late binding with the content server, and
ignoring the ACLs. I know this because I get correct secure results
only if I give the right password. If I give the wrong password, then
I get no secure results. So without an authentication provider,
apparently the GSA does not apply ACLs.