[Web Comm] Single Sign On SSO

[Daniel Brookshier]

I have submitted your questions to support to see what they say. Not  
sure about the LDAP being possible. We are using a MYSQL database for  
this sort of thing I believe. But we will see what they say about  
interfacing to such a puppy.

Daniel Brookshier | Community Manager | CollabNet, Inc.
8000 Marina Blvd. Suite 600 | Brisbane, CA 94005 | USA
O 972.422.5261 | C 214.207.6614 | dbrookshier at collab.net


On Mar 31, 2006, at 12:44 PM, Frank Warmerdam wrote:

> Daniel Brookshier wrote:
>> Hi all,
>> In pursuit of our discussions about linking the OSGeo ID with any  
>> other hosted tools, I have the following information from our  
>> operations. Note that SSO integration will likely incur a cost,  
>> but I am unaware of the specific amount. 3/30/2006 6:39 AM |  
>> Karishma Jugal
>> Daniel,
>> The request for an SSO would require a Statement of Work (SOW)  
>> which needs to come through Services. Once the SOW has been  
>> created, the Engineering Operations would provide the list of  
>> requirements expected from the customer. Once the information has  
>> been collected, they would prepare an instance set that would be  
>> applied on the site for enabling dual authentication.
>> The customer may require to do the following (the complete list  
>> would be specified in the SOW):
>> 1) Provide CollabNet with detailed information about the OSGeo  
>> subdomain server's cookie format.
>> 2) Appoint a project manager, who would act as an interface  
>> between Autodesk and CollabNet during this project.
>> The Engineering Operations would negotiate with the Project  
>> Manager appointed by the customer to collect more detailed  
>> information like:
>> 1) The contents of the session cookie required from the customer's  
>> site when a user logs in. The contents may include User session  
>> ID, User name, Email address, Real Name, Organization.
>> 2) The design of the SSO environment.
>> 3) Other information that might be necessary for the dual  
>> authentication. (a complete list would be provided by the  
>> Engineering Operations)
>> The only difference between today and the future (if there is a  
>> more standard API) is that currently this information is collected  
>> manually, and an instance set is applied on the site based on that  
>> information. But in the future, if the platform has a more  
>> standard API for this, the information would be collected through  
>> GUI and the configuration changes would be applied instantly.
>> Please let us know if this information answered your query. Please  
>> feel free to get back to us for more information.
>
> Daniel,
>
> Thanks, this was helpful.
>
> Right now I see that the osgeo.org has three cookies in my cookie  
> cache.
> Two that are apparently session ids, and one called "MDAAuth" that
> has the contents:
>
>  "78fe1....d2888b07879f2442d6d9dwarmerdam at pobox.com!8000!"
>
> I am guessing that when I visit a page at osgeo.org, the MDAAuth
> cookie is checked against some sort of database to see if I am logged
> in and if so, who I am. Is that right?
>
> Would the "SSO" proposal be to provide a service whereby external
> components of the osgeo.org domain (ie. wiki.osgeo.org) could
> authenticate the same cookie?  Forgive me for being a bit dense.
> This isn't my area of specialty.
>
> My generally impression is that sharing login information stuff  
> between
> outside components and the CN provided systems is going to be pretty
> involved.  Perhaps for now we could pursue a "two signon" solution
> where the external systems are run off a central LDAP server at
> telescience.  At least that would be more managable than separate
> userid silos for every external service.
>
> Best regards,
> -- 
> --------------------------------------- 
> +--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGF, http:// 
> osgeo.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at webcommittee.osgeo.org
> For additional commands, e-mail: dev-help at webcommittee.osgeo.org
>