Sharepoint Connector / Single Sign On

[tm]

Hi,

We've got a Sharepoint v2 Connector up and running succesfully via
content feed. We have chosen to use authorization by Connector, as
opposed to by appliance or via SAML auth provider.

We have also ensured the Connector was installed by a user on the same
Windows domain as the users we want to provide single sign on to our
MOSS install/search results for. This Connector is also using an
account on that same domain to access MOSS. Google Services are
installed on the MOSS install.

My question is - should having the above configuration mean that the
Connector itself can provide single sign on functionality? i.e. if a
user on that domain ran a search for secure content, would they still
get prompted to enter their Windows credentials to view the secure
results?

What I've found is that despite the above config, users are still
presented with a login box. The documentation *seems* to suggest we
will still need to set up Google SAML bridge for sso, even if we
choose auth by Connector and content feeds?

Cheers.

[tm]

Actually just did a bit more research, think I may have misunderstood
this... sounds like the Google Search Box for Sharepoint will provide
SSO? We would like to use our own Sharepoint web parts to request
search results as xml from the GSA, then customise the look and feel
in Sharepoint.

(Also, our Google Services were probably installed on the MOSS host
under a user on another domain to the "main" one we want sso for. Not
sure if this would have any impact or not?)

Thanks again.

[jeff ling]

If you are using GSA 5.2 or later, you can use GSA's onboard Kerberos (IWA) support to provide SSO experience to your users. 

The Search Box is really intended to provide the "search box" inside SharePoint, and it depends on both GSA and SharePoint to be using Kerberos.

The Google services are just some web service pages, and they will run in the context of the SP service (IIS).

Jeff

[tm]

Thanks for your reply- I actually found some info stating the Google
Search Box for SharePoint can handle silent auth with no extra
configuration required on the GSA (if using HTTP basic auth):

"Authentication on the Search Box is performed silently. The Search
Box uses the currently logged-in user for authorization and does not
ask users to enter their credentials again. The Search Box supports
the HTTP Basic and Kerberos authentication protocols, with some
constraints."

For our project ideally we don't want to use the Google Search Box for
Sharepoint, but we would like to find a way to perform silent auth for
our users who will be running searches from Sharepoint.

At this stage we are looking to develop various SharePoint components
which will be querying for XML result sets from the GSA, so we're
trying to figure out the best way to do silent auth. Hence we're
trying to unravel how the Google Search Box for Sharepoint does
this...

Cheers.

On Oct 1, 4:54 pm, jeff ling <jeffreyl...@gmail.com> wrote:
> If you are using GSA 5.2 or later, you can use GSA's onboard Kerberos (IWA)
> support to provide SSO experience to your users.
>
> The Search Box is really intended to provide the "search box" inside
> SharePoint, and it depends on both GSA and SharePoint to be using Kerberos.
>
> The Google services are just some web service pages, and they will run in
> the context of the SP service (IIS).
>
> Jeff
>

[rakesh_shete]

If you want to understand how Google Search Box does this, you can
have a look here:

http://code.google.com/p/google-enterprise-connector-sharepoint/source/browse/tags/GSBS1.0.0/searchresults.aspx

The SSO behavior is driven by what authN scheme is on your SharePoint
(Kerberos, HTTPBasic or NTLM). For Kerberos, HTTPBasic GSA's HEAD
request will work. For NTLM it will not. You require some kind of SAML
provider to handle authN and then authZ can be handled by connector or
your SAML provider.

The key is passing the relevant info of the currently logged-in user
from the browser to GSA such that GSA does not require to prompt user
for authN or authZ

--Rakesh S

[Michael Cizmar]

Utilizing a web part as a proxy has some issues if you are not in a
100% kerberos environment. I believe the connector manager will
prompt you for credentials if you have not authenticated to the
appliance via Kerberos and .NET will not pass your identity forward if
you authenticate with NTLM which is always a issue.

I wrote an easier example to integrating SharePoint with the GSA here:

http://www.mcplusa.com/blog/2009/08/can-the-google-mini-index-sharepoint/

It basically uses an iFrame. This facilitates how the GSA (and Mini)
were designed to be interacted with.

If you do not have Kerberos enabled and are using a SAML, I wrote the
code that you need to hand shake with the appliance here:

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

Otherwise, the appliance is going to prompt you for credentials and
the .NET web part is going send then nothing.

Cheers,



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

> > Cheers.- Hide quoted text -
>
> - Show quoted text -

[rakesh_shete]

Thanks!

This helps a lot!

--Rakesh S

On Oct 2, 5:47 am, Michael Cizmar <michael.b.ciz...@gmail.com> wrote:
> Utilizing a web part as a proxy has some issues if you are not in a
> 100% kerberos environment.  I believe the connector manager will
> prompt you for credentials if you have not authenticated to the
> appliance via Kerberos and .NET will not pass your identity forward if
> you authenticate with NTLM which is always a issue.
>
> I wrote an easier example to integrating SharePoint with the GSA here:
>

> http://www.mcplusa.com/blog/2009/08/can-the-google-mini-index-sharepo...

>
> It basically uses an iFrame.  This facilitates how the GSA (and Mini)
> were designed to be interacted with.
>
> If you do not have Kerberos enabled and are using a SAML, I wrote the
> code that you need to hand shake with the appliance here:
>

> http://www.mcplusa.com/blog/2009/06/remotely-calling-the-google-searc...

>
> Otherwise, the appliance is going to prompt you for credentials and
> the .NET web part is going send then nothing.
>
> Cheers,
>
> --
> Michael Cizmar | MC+A

> Google Enterprise Partnerwww.mcplusa.com| twitter:http://www.twitter.com/mcplusa

[tm]

Thanks, that's what I was after!

On Oct 2, 12:32 pm, rakesh_shete <rakeshs101...@gmail.com> wrote:
> If you want to understand how Google Search Box does this, you can
> have a look here:
>

> http://code.google.com/p/google-enterprise-connector-sharepoint/sourc...

[tm]

Thank you - that second link you posted is really what we're looking
to get our heads around. Ideally we don't want to just iframe the
results page, we're going to need to get the raw XML back from the GSA
and process that.

Cheers.

On Oct 3, 1:47 am, Michael Cizmar <michael.b.ciz...@gmail.com> wrote:
> Utilizing a web part as a proxy has some issues if you are not in a
> 100% kerberos environment.  I believe the connector manager will
> prompt you for credentials if you have not authenticated to the
> appliance via Kerberos and .NET will not pass your identity forward if
> you authenticate with NTLM which is always a issue.
>
> I wrote an easier example to integrating SharePoint with the GSA here:
>

> http://www.mcplusa.com/blog/2009/08/can-the-google-mini-index-sharepo...

>
> It basically uses an iFrame.  This facilitates how the GSA (and Mini)
> were designed to be interacted with.
>
> If you do not have Kerberos enabled and are using a SAML, I wrote the
> code that you need to hand shake with the appliance here:
>

> http://www.mcplusa.com/blog/2009/06/remotely-calling-the-google-searc...

>
> Otherwise, the appliance is going to prompt you for credentials and
> the .NET web part is going send then nothing.
>
> Cheers,
>
> --
> Michael Cizmar | MC+A

> Google Enterprise Partnerwww.mcplusa.com| twitter:http://www.twitter.com/mcplusa

[tm]

One more q - so is this whole process a little more straightforward
using Kerberos? (i.e. GSA using it, browsers set up for it, Sharepoint
set up for it.)

In particular I'm referring to single sign on and and Sharepoint/.NET
work required.

Cheers.

On Oct 3, 1:47 am, Michael Cizmar <michael.b.ciz...@gmail.com> wrote:

> Utilizing a web part as a proxy has some issues if you are not in a
> 100% kerberos environment.  I believe the connector manager will
> prompt you for credentials if you have not authenticated to the
> appliance via Kerberos and .NET will not pass your identity forward if
> you authenticate with NTLM which is always a issue.
>
> I wrote an easier example to integrating SharePoint with the GSA here:
>

> http://www.mcplusa.com/blog/2009/08/can-the-google-mini-index-sharepo...

>
> It basically uses an iFrame.  This facilitates how the GSA (and Mini)
> were designed to be interacted with.
>
> If you do not have Kerberos enabled and are using a SAML, I wrote the
> code that you need to hand shake with the appliance here:
>

> http://www.mcplusa.com/blog/2009/06/remotely-calling-the-google-searc...

>
> Otherwise, the appliance is going to prompt you for credentials and
> the .NET web part is going send then nothing.
>
> Cheers,
>
> --
> Michael Cizmar | MC+A

> Google Enterprise Partnerwww.mcplusa.com| twitter:http://www.twitter.com/mcplusa

[Michael Cizmar]

Absolutely. When you have Kerberos enabled the identity of the logged
in user can be passed to all web services that support Kerberos. So
you do in effect get a Single Sign On experience. All of the content
sources that the GSA indexes as secure will need to support Kerberos
or you're left back to the SAML option.

Michael Cizmar | MC+A

Google Enterprise Partner
www.mcplusa.com | twitter: http://www.twitter.com/mcplusa

[tm]

Cool, thanks again Michael.

On Oct 6, 3:21 pm, Michael Cizmar <michael.b.ciz...@gmail.com> wrote:
> Absolutely.  When you have Kerberos enabled the identity of the logged
> in user can be passed to all web services that support Kerberos.  So
> you do in effect get a Single Sign On experience.  All of the content
> sources that the GSA indexes as secure will need to support Kerberos
> or you're left back to the SAML option.
>
> Michael Cizmar | MC+A

> Google Enterprise Partnerwww.mcplusa.com| twitter:http://www.twitter.com/mcplusa