[Web Comm] Single Sign On SSO

[Arnulf Christl]

Daniel Brookshier wrote:
> 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,

Hi,
I would second the proposal of setting up an LDAP at our secondary 
hosting environment (could we call it that?). It has still not been 
worked out how SSO is going to be implemented using OGC interfaces 
either. In the long run we will want to have SSO including the Wiki, the 
OSGeo domain *and* the OSGeo SDI stack. That would be cool. Maybe add 
some GeoACXML certification to the process, reduces the overhead of 
logging into LDAPs and reading Cookies across domain limits.

Maybe I have missed it but there was some talk about an infrastructure 
workgroup/taskforce/someone for the telescience. Latest information that 
I have is that Mark Lucas is the SSO/CVS for this topic and Norman Vine 
one of the setup scripts / executables. :-) Correct?

Best, Arnulf.