Controlled Access Content

I'm reading over this stuff on "Controlled Access
Content"....
http://code.google.com
/apis/searchappliance/documentation/46/admin_crawl/Introduct
ion.html
http://cod
e.google.com/apis/searchappliance/documentation/46/secure_se
arch/secure_search_overview.html
...and maybe I'm just not all here today mentally, but I'm
not
completely getting this.

Here's our situation - most of our sites will just be all
public
content and I'm comfortable with how that will work.  But
one of our
upcoming sites will not be so easy.  This site will be
http://professi
onal.bariatricedge.com (pro.be.com, for short). ( And
because this site doesn't exist yet, I'm going to play with
it3-
dtcfhelp.eadv.na.jnj.com in the mean time, to master our
approach. )

On pro.be.com all content is secure ( protected behind
authentication
and authorization ).  Our J2EE application that runs these
site
( which is named CODI ), does it's own form based
authentication and
stores the user's logged-in status in their J2EE session.
When
authenticated, users are assigned roles ( again stored in
their J2EE
session ) and those roles effect what content they can see. 
For
example, users with Role A can get to this content, users
with Role B
can get to some other content, users with Role A and Role B
can get to
all content.  If a user requests content they're not
authorized for,
they get a nice "sorry, not for you" page served
by our application.
In order to even get to the search page on this application,
the user
will have to be authenticated.

So here's my impression of how pro.be.com might work with
the Google
appliance...

To get all the content indexed, I'll provide you with a
username/
password that has all roles and thus has access to all
content on the
site.  Though I can't find any detailed evidence of it in
the docs, I
assume I'll also need to give you the URL of login form
page?  Does
google require that the login form have particular input
names?  Can
you setup a Form Authentication Rule that just says the
whole site is
protected?

But I start to get really lost in the docs when it talks
about how the
secure results are returned in a search.  It claims it's
going to
filter the results of the search down to what the user is
authorized
to see.  But I completely don't understand how it's going to
do that
smoothly.  To quote the document:
When a user performs a search request, the search appliance
performs
two checks before serving secure content:
    * The search appliance acquires the user's credentials
to enable
impersonation, or performs an authentication check to
establish the
user's identity.
    * The search appliance impersonates the user, or
performs an
authorization check to determine whether the user can view
the
content. If the user is authorized to view the content, the
content
will appear in the user's search results.
If a secure content item fails the second check, the search
appliance
removes it from the list of results.
(from
http://code.google.com/apis/searcha
ppliance/documentation/46/secure_search/secure_search_crwlsr
v.html#serve_for_controlled_access_content)
I can't seem to get my head around how it "acquires the
user's
credentials" to make the 0 byte GET request ( mentioned
later in the
doc) to check authorization.
Can you explain how this will work?  Will it make the user
login again
to do it?

Another relevant point, that may complicate this even more,
is that
we're going to use a custom presentation that will involve
issuing the
search request from our application, to the google
appliance, getting
back XML, and then converting that to a full page on our
site.  This
will allow us to frame the results within the shell of our
sites
( showing the site's header, footer, menu, etc).


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Search Appliance" group.
To post to this group, send email to
Google-Search-Appliancegooglegroups.com
To unsubscribe from this group, send email to
Google-Search-Appliance-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/Google-Search-Applian
ce?hl=en
-~----------~----~----~----~------~----~------~--~---

I'll see if I can help... Reply is inline, below.

[...]
> So here's my impression of how pro.be.com might work
with the Google
> appliance...
>
> To get all the content indexed, I'll provide you with a
username/
> password that has all roles and thus has access to all
content on the
> site.  Though I can't find any detailed evidence of it
in the docs, I
> assume I'll also need to give you the URL of login form
page?  Does
> google require that the login form have particular
input names?  Can
> you setup a Form Authentication Rule that just says the
whole site is
> protected?

The method used depends on the type of login form that
pro.be.com
uses. See the table in
http://code.google.com/apis
/searchappliance/documentation/50/secure_search/secure_searc
h_overview.html#which_sections_of_this_guide_should_i_read
for a list of different kinds of login forms and the method
you should
use.

I've copied the relevant section from the table here
(forgive the
reformatting):

Single login domain: one set of domain credentials provides
access to
all content, but the login form uses frames or Javascript.
  Google Search Appliance only
    - can be public or secure
    - Crawl: Forms Authentication
    - Serve: Forms Authentication with an external login
server:
http://c
ode.google.com/apis/searchappliance/documentation/50/secure_
search/secure_search_crwlsrv.html#enabling_forms_authenticat
ion_through_an_external_login_server

Single login domain: one set of domain credentials provides
access to
all content. The login form is plain HTML.
  Google Search Appliance only
    - can be public or secure
    - Crawl: Forms Authentication
    - Serve: Forms Authentication with cookie forwarding:
http://code.goo
gle.com/apis/searchappliance/documentation/50/secure_search/
secure_search_crwlsrv.html#enabling_forms_authentication_thr
ough_cookie_forwarding

Single login domain: one set of domain credentials provides
access to
all content, but cookies are subject to IP restrictions or
you have
multiple cookie domains. 	  Google Search Appliance only
    - can be public or secure
    - Crawl: Forms Authentication
    - Serve: Forms Authentication with user impersonation:
http://code.go
ogle.com/apis/searchappliance/documentation/50/secure_search
/secure_search_crwlsrv.html#enabling_forms_authentication_th
rough_user_impersonation

The methods differ slightly, but for all cases, you enter
the URL in
the URL field under Serving > Forms Authentication . If
your login
form doesn't use frames or Javascript, you probably want
Forms
Authentication with Cookie Forwarding. As you guessed, this
method
will apply for the whole site.


> But I start to get really lost in the docs when it
talks about how the
> secure results are returned in a search.  It claims
it's going to
> filter the results of the search down to what the user
is authorized
> to see.  But I completely don't understand how it's
going to do that
> smoothly.
[...]
> I can't seem to get my head around how it
"acquires the user's
> credentials" to make the 0 byte GET request (
mentioned later in the
> doc) to check authorization.
> Can you explain how this will work?  Will it make the
user login again
> to do it?
>

Nope! The user only has to log in once with Forms-based
Authentication.

How this works depends on the type of Forms-based
authentication that
you're using. For a step-by-step description of what
happens, see use
case 4 (cookie forwarding), use case 5 (external login), or
use case 6
(user impersonation) on this page:
http://co
de.google.com/apis/searchappliance/documentation/46/secure_s
earch/secure_search_formsauth.html

> Another relevant point, that may complicate this even
more, is that
> we're going to use a custom presentation that will
involve issuing the
> search request from our application, to the google
appliance, getting
> back XML, and then converting that to a full page on
our site.  This
> will allow us to frame the results within the shell of
our sites
> ( showing the site's header, footer, menu, etc).

This shouldn't be a problem. As long as your application and
the
search appliance are on the same cookie domain, and any
session
cookies set on the user's computer can be passed to the
search
appliance in the request, it should work the way you
describe.

Good luck!

-ndb


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Google Search Appliance" group.
To post to this group, send email to
Google-Search-Appliancegooglegroups.com
To unsubscribe from this group, send email to
Google-Search-Appliance-unsubscribegooglegroups.com
For more options, visit this group at http://groups.google.com/group/Google-Search-Applian
ce?hl=en
-~----------~----~----~----~------~----~------~--~---