GoGrid Needs to Rethink Security

54 views
Skip to first unread message

Shane Jones

unread,
Sep 5, 2008, 2:03:48 AM9/5/08
to Cloud Computing
Let me start by saying that I like GoGrid. I think they are a viable
player in the cloud computing space, and I hope they do well. I'm
starting this discussion so they and all of us can learn together to
build credibility for cloud computing in general.

We all know that security is only as strong as your weakest link and
you never get a second change to make a first impression. With so
many people already skeptical of cloud computing, we need to make sure
that people's first experience with cloud computing is a positive one.

GoGrid has failed to secure the most basic component of IT security -
customers' passwords. When you try to login to GoGrid's control
panel, the screen doesn't provide any way to retrieve your username
and password. If you lose it, you have to contact customer support to
retrieve it. In and of itself, this is a big oversite.

I contacted customer support through their online live chat support.
My expectation was that they would either point me to a page where I
could go through a process of requesting a password reset or that they
would have to reset my password and the system would automatically
send it to my email address.

The support rep asked for my name, email address, and billing address
for the credit card on file. What happened next, was a complete shock
to me...in the chat window, there was my password in plain text. Not
only did the rep have access to my password (which is completely
unacceptable), but they actually gave it to me without any real
assurance that I was who I said I was.

Getting someone's name, email address, and billing address is about as
easy as it gets - especially in the corporate world.

Bill Gates, bi...@microsoft.com, One Microsoft Way, Redmond, WA 98052

I'm sure Bill isn't a GoGrid customer, but you get the point. As an
industry, we have to be a lot better than this if we expect to earn
the trust of enterprise customers. I know that the GoGrid team is
strong and they'll correct this problem very quickly, but it should be
an eye opener for all of us.

-shane

Shane Jones
Chief Executive Officer, CloudRamp, Inc.
Blog: www.cloudramp.com
Twitter: www.twitter.com/cloudramp

sudhendra seshachala

unread,
Sep 5, 2008, 9:45:31 AM9/5/08
to cloud-c...@googlegroups.com
I noticed this too. I guess, they are still in beta, so hopefully they will get better in this area.
 
thanks
Sudhi

 

Reuven Cohen

unread,
Sep 5, 2008, 10:13:44 AM9/5/08
to cloud-c...@googlegroups.com

Amazon is also in beta. I'm not sure if being in beta is any excuss
for poor security policies. Do they do this for their traditional
hosting plans?

reuven

Michael Sheehan

unread,
Sep 5, 2008, 10:24:32 AM9/5/08
to Cloud Computing
Shane,

Thank you for pointing this out. I will be sure that our support team
knows not to give out this type of information, or if it is given out,
it is done in a secure manner.

Security is of utmost importance to us. If you have any other
suggestion on how we can increase your comfort level (e.g., with
password hints, temporary password resets, etc.) please let me know.

Do note that our entire GoGrid portal is run with SSL-encryption,
INCLUDING the chat session so while I agree with you that the password
should not have been delivered in that manner, the chat session was
encrypted with RC4 128 bit encryption.

Thanks,
Michael Sheehan
Technology Evangelist for GoGrid

Khazret Sapenov

unread,
Sep 5, 2008, 10:33:52 AM9/5/08
to cloud-c...@googlegroups.com
On Fri, Sep 5, 2008 at 10:24 AM, Michael Sheehan <mic...@servepath.com> wrote:

Shane,

Thank you for pointing this out. I will be sure that our support team
knows not to give out this type of information, or if it is given out,
it is done in a secure manner.

Security is of utmost importance to us. If you have any other
suggestion on how we can increase your comfort level (e.g., with
password hints, temporary password resets, etc.) please let me know.

Do note that our entire GoGrid portal is run with SSL-encryption,
INCLUDING the chat session so while I agree with you that the password
should not have been delivered in that manner, the chat session was
encrypted with RC4 128 bit encryption.

I think one of Shane's point is that support shouldn't have access to clear text passwords at all and should have stronger authentication procedure of the customer (3-4 factor plus). 

This single incident might make one think the entire system has same level of protection, which doesn't create more comfort. 

Michael Sheehan

unread,
Sep 5, 2008, 11:16:08 AM9/5/08
to Cloud Computing
Khazret,

I will go out on a limb here and say that it does NOT reflect the
general state of security. As I mentioned previously, all of GoGrid
runs under 128-bit SSL encryption. Some further background. GoGrid is
a product of ServePath who does managed hosting and colocation. We
have been doing this for over 7 years and have very robust security
protocols and procedure for our entire organization (SAS70 certified
as well).

The password delivery over chat is a serious matter that we will
address promptly. I would ask simply that people don't make
assumptions on the quality or security of the product due to a human
interaction (e.g., an action on chat) as it may not reflect the
product itself.

Thanks,
Michael

On Sep 5, 7:33 am, "Khazret Sapenov" <sape...@gmail.com> wrote:

Shane Jones

unread,
Sep 5, 2008, 11:22:15 AM9/5/08
to Cloud Computing
Thanks Michael. Just to let everyone know, I did let the support team
know about this issue before posting it to the board, and they said
they would escalate this to the right people.

I would suggest the following:

1. Add a password reset function to the login page that generates a
new, random password and emails it directly to the primary email
address of the main administrator.

2. Eliminate the internal tool that the support team uses to access
customer passwords and train them to redirect people to the automated
reset function.

3. Long term, it would be great if you allowed the administrator to
set their own policies on how passwords could be retrieved/reset. For
example, the user could require both an email address and primary
credit card number be passed to the password reset function. The
password reset function should be able to have access to an encrypted
version of the credit card number to compare to an encrypted version
of the number provided by the user without presenting a security risk.

Another concern that I have is whether or not server passwords stored
inside the control panel are accessible to the support team. I
assumed that when you change a server password inside the control
panel, it would change the account password on the virtual server. I
contacted support after my login failed, and he said that the
passwords stored inside the control panel are not connected to the
virtual servers, and that they were "just for our reference". At the
time, I assumed he meant just for *my* reference. But the more I
think about it, he retrieved my original password for the virtual
server, he didn't reset it. I'm guessing that they have a similar
tool that lets them retrieve passwords for each virtual server
account? If so, that needs to be changed as well.

Thanks again Michael for your quick response and seeing that these
issues get resolved.

-shane
> > Twitter:www.twitter.com/cloudramp- Hide quoted text -
>
> - Show quoted text -

Michael Sheehan

unread,
Sep 5, 2008, 11:36:53 AM9/5/08
to Cloud Computing
Hi Shane,

Thanks for the details. Your points are exactly what I was thinking as
well. Points #2 and 3 are great as well.

The other suggestions that you have are intriguing as well. The
passwords that are displayed within the GoGrid portal are there for
reference and do not reflect the current state of a password on a
GoGrid server. Think of it as a notepad. You can update it manually
(say, for example, you have a team of developers that you need to
share this information with). We wanted to create a utility that would
be self-serving and automated for when you created a cloud server. We
didn't want to email user/password information for newly created
servers because of the security concerns. So, we developed a slick way
that automagically creates the user/pass combo that populates the
password section. Once you go in to your server, though, it is up to
you to manage them.

In terms of not allowing support to view passwords, this is a tricky
thing. Since we do provide (free) 24x7 support for GoGrid, we needed
to be sure that we could provide support (to some extent) within the
server itself. I can't really talk about the "behind the scenes" magic
that makes that work, but it is a pretty complex and well vetted
process that continues to evolve.

Anyway, thanks for your ideas!

-Michasel
> > > Twitter:www.twitter.com/cloudramp-Hide quoted text -

Adwait Ullal

unread,
Sep 5, 2008, 11:38:32 AM9/5/08
to cloud-c...@googlegroups.com
 
In addition to Shane's suggestions below, encypt (not just transit via SSL, etc) or hash the password in storage if it's not being done already. Also the email that's being send should never contain both the password and the userid in the same email.
 
- Adwait

--
Adwait Ullal

w: http://www.adwait.com
p: (408) 898-2581
 
On 9/5/08, Shane Jones <shane...@gmail.com> wrote:

Vishal Mehra

unread,
Sep 5, 2008, 12:03:15 PM9/5/08
to cloud-c...@googlegroups.com
Hi Michael,

CSRs (Customer Service Reps) should not have the ability to view any customers' passwords. In fact, all passwords should be "one-way" hashed before they are stored in the secured database that has limited access. Most of the secured transactional oriented sites would allow users to reset the password rather than retrieve the password - perhaps you want to evaluate GoGrid's architecture based on type of applications that would be hosed on the environment. If there is a need for CSRs to impersonate as a customer, they should login with their super id, and this id along with customer id (and operation performed) should be recorded in the database for audit purposes.

Vishal

Michael Sheehan

unread,
Sep 5, 2008, 1:15:32 PM9/5/08
to Cloud Computing
Vishal,

Great suggestions! Thanks for the info. I'm not privy to how things
are actually architected so we may be actually doing that.

-Michael

On Sep 5, 9:03 am, "Vishal Mehra" <vishal.m.me...@gmail.com> wrote:
> Hi Michael,
>
> CSRs (Customer Service Reps) should not have the ability to view any
> customers' passwords. In fact, all passwords should be "one-way" hashed
> before they are stored in the secured database that has limited access. Most
> of the secured transactional oriented sites would allow users to reset the
> password rather than retrieve the password - perhaps you want to evaluate
> GoGrid's architecture based on type of applications that would be hosed on
> the environment. If there is a need for CSRs to impersonate as a customer,
> they should login with their super id, and this id along with customer id
> (and operation performed) should be recorded in the database for audit
> purposes.
>
> Vishal
>
> > > > > Twitter:www.twitter.com/cloudramp-Hidequoted text -

Brendon Whateley

unread,
Sep 5, 2008, 2:40:30 PM9/5/08
to cloud-c...@googlegroups.com
One of the important reasons for using a one-way-hash for passwords is to prevent the original password from being ever discovered or recovered.  Part of the security concern is that many people reuse passwords for other services, so if you leak a plain text password, there is a good chance that you could log into other services that the same customers uses.

There is no compelling reason for designing a system that allows a customer password to be recovered.  The security risk from somebody gaining access to the password database goes from almost zero to huge, for no operational benefit.  If the support people can reset and supply a new one-time password over a secure chat session or even over email, that could be a completely acceptable risk.  If they can recover my password, that makes me cringe...

Brendon.

Dan Kearns

unread,
Sep 5, 2008, 3:03:46 PM9/5/08
to cloud-c...@googlegroups.com
On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley <bre...@darkindigo.com> wrote:
There is no compelling reason for designing a system that allows a customer password to be recovered.  The security risk from somebody gaining access to the password database goes from almost zero to huge, for no operational benefit

Sidestepping the horror that hashing even needs to be explained to a web based service provider....

It's actually unavoidable to store real passwords in cloud apps, as there is no trust or delegation model between services (that matter) which is usable or widespread enough to "just work". It doesn't seem to be for lack of effort though, as uncountably many companies and standards have been involved.

It's probably too low-tech to suit most folks, but I'd like to see a cloud service created which does the following:
  • stores my ids/passwords in a way where I have a reasonable expectation it won't be compromised
  • provides an id/password on demand to anyone who a) asks for it, and b) I have approved for access to it and c) which the service provider has contractually obligated not to persist it locally under penalty of a monetary value known to me

-d

Adwait Ullal

unread,
Sep 5, 2008, 3:18:51 PM9/5/08
to cloud-c...@googlegroups.com
 
OpenID (www.openid.net) ?
 
- Adwait

--
Adwait Ullal

w: http://www.adwait.com
p: (408) 898-2581
 

Brendon Whateley

unread,
Sep 5, 2008, 3:21:17 PM9/5/08
to cloud-c...@googlegroups.com

That sounds a lot like OpenID.   That seems to be gaining traction at the moment and has a bunch of nice features.

Access control and authorization are getting to be bigger hurdles as more stuff moves into the cloud.  And the impact of compromise is growing!

Brendon.

Dan Kearns

unread,
Sep 5, 2008, 3:33:44 PM9/5/08
to cloud-c...@googlegroups.com
On Fri, Sep 5, 2008 at 12:18 PM, Adwait Ullal <adwait...@gmail.com> wrote:
 OpenID (www.openid.net) ?
 
On 9/5/08, Dan Kearns <d...@thekearns.org> wrote:
It's actually unavoidable to store real passwords in cloud apps, as there is no trust or delegation model between services (that matter) which is usable or widespread enough to "just work". It doesn't seem to be for lack of effort though, as uncountably many companies and standards have been involved.

never heard of it.

seriously though, note the keywords: trust, delegation, usable, and widespread.

Then try to imagine a yodlee or travelocity saying "I know, we'll just use openid"

-d

Krishna Sankar (ksankar)

unread,
Sep 5, 2008, 4:01:07 PM9/5/08
to cloud-c...@googlegroups.com

We can do that with OpenID and OAuth. Actually we can do it with better granularity.

Cheers

<k/>  

Rich Wellner

unread,
Sep 5, 2008, 4:53:03 PM9/5/08
to cloud-c...@googlegroups.com


It's probably too low-tech to suit most folks, but I'd like to see a cloud service created which does the following:
  • stores my ids/passwords in a way where I have a reasonable expectation it won't be compromised
  • provides an id/password on demand to anyone who a) asks for it, and b) I have approved for access to it and c) which the service provider has contractually obligated not to persist it locally under penalty of a monetary value known to me

The grid community solved this with GSI and delegated credentials.

The primary motivations behind the GSI are:

    * The need for secure communication (authenticated and perhaps confidential) between elements of a computational Grid.
    * The need to support security across organizational boundaries, thus prohibiting a centrally-managed security system.
    * The need to support "single sign-on" for users of the Grid, including delegation of credentials for computations that involve multiple resources and/or sites.


There is almost certainly some stuff there worth considering for use in clouds.

rw2

Tim Freeman

unread,
Sep 5, 2008, 6:23:27 PM9/5/08
to cloud-c...@googlegroups.com, goo...@objenv.com
On Fri, 05 Sep 2008 15:53:03 -0500
Rich Wellner <goo...@objenv.com> wrote:

>
> >
> > It's probably too low-tech to suit most folks, but I'd like to see a
> > cloud service created which does the following:
> >

> > * stores my ids/passwords in a way where I have a reasonable


> > expectation it won't be compromised

> > * provides an id/password on demand to anyone who a) asks for it,


> > and b) I have approved for access to it and c) which the service
> > provider has contractually obligated not to persist it locally
> > under penalty of a monetary value known to me
> >
>
> The grid community solved this with GSI

> <http://www.globus.org/security/overview.html> and delegated credentials.

That link is pretty out of date, in particular:

"Note that the GSI and software based on it (notably the Globus Toolkit,
GSI-SSH, and GridFTP) is currently the only software which supports the
delegation extensions to TLS (a.k.a. SSL). The Globus Project is actively
working with the Grid Forum and the IETF to establish proxies as a
standard extension to TLS so that GSI proxies may be used with other TLS
software."

See: http://www.ietf.org/rfc/rfc3820.txt

OpenSSL has support for this since 2005 I believe.

>
> /The primary motivations behind the GSI are:


>
> * The need for secure communication (authenticated and perhaps
> confidential) between elements of a computational Grid.
> * The need to support security across organizational boundaries,
> thus prohibiting a centrally-managed security system.
> * The need to support "single sign-on" for users of the Grid,
> including delegation of credentials for computations that involve

> multiple resources and/or sites. /


>
> There is almost certainly some stuff there worth considering for use in
> clouds.

We use it with Nimbus for client -> management interactions:

http://workspace.globus.org

As for what happens on VMs, the Nimbus automatic configuration technology can
take you from no secrets to a bootstrapped security context using just about any
technology (including remote access policies as well as SSH host key
distribution/authentication across your launched VMs):

http://workspace.globus.org/clouds/clusters.html#features

This "overlay" technology is good in my opinion because only a small amount of
"cooperation" is necessary from the various VM-as-resource providers (namely,
help to get a seed secret on to the VM).

We've spoken with AWS evangelists etc. about some kind of delegation for EC2
operations -- it is a natural fit for the ecosystem of businesses running
things on clients' behalf (many companies are getting into this, it would be
good for our users that run via a Nimbus backend to EC2 as well).

Uploading your raw credentials to a remote management application is
unnecessary and risky...

Tim


>
> rw2
>
>
> >

Michael Sheehan

unread,
Sep 5, 2008, 6:33:06 PM9/5/08
to Cloud Computing
For those who have been following this thread, I just posted more
information and some changes that we have put into effect (today) to
mitigate some of the concerns that users have.

More information is here: http://blog.gogrid.com/2008/09/05/gogrid-password-security-update/

Feel free to contact me with any questions, concerns or suggestions
you may have.

Thanks,
Michael

On Sep 4, 11:03 pm, Shane Jones <shanedjo...@gmail.com> wrote:

Robert W. Anderson

unread,
Sep 5, 2008, 6:35:30 PM9/5/08
to cloud-c...@googlegroups.com

OpenID doesn’t do anything like what is being suggested.   Several OpenID providers are building identity services that do support the single sign-on password management. 

 

But we aren’t really even talking about single sign-on here.  We’re talking about delegation.  OAuth, SAML, and I think GSI have solutions for this, but OpenID?  Not what is was designed for.

 

 

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Adwait Ullal
Sent: Friday, September 05, 2008 12:19 PM
To: cloud-c...@googlegroups.com
Subject: Re: GoGrid Needs to Rethink Security

 

 

OpenID (www.openid.net) ?

<br

Tim Freeman

unread,
Sep 6, 2008, 12:26:08 AM9/6/08
to cloud-c...@googlegroups.com, ksa...@cisco.com
On Fri, 5 Sep 2008 13:01:07 -0700
"Krishna Sankar (ksankar)" <ksa...@cisco.com> wrote:

> We can do that with OpenID and OAuth. Actually we can do it with better
> granularity.

Here is a slightly old, but I think still relevant, discussion of OpenID cons:

http://idcorner.org/2007/08/22/the-problems-with-openid/

Tim


>
> Cheers
>
> <k/>
>
>
>
> From: cloud-c...@googlegroups.com
> [mailto:cloud-c...@googlegroups.com] On Behalf Of Dan Kearns
> Sent: Friday, September 05, 2008 12:04 PM
> To: cloud-c...@googlegroups.com
> Subject: Re: GoGrid Needs to Rethink Security
>
>
>
> On Fri, Sep 5, 2008 at 11:40 AM, Brendon Whateley
> <bre...@darkindigo.com> wrote:
>
> There is no compelling reason for designing a system that allows
> a customer password to be recovered. The security risk from somebody
> gaining access to the password database goes from almost zero to huge,
> for no operational benefit
>
>
> Sidestepping the horror that hashing even needs to be explained to a web
> based service provider....
>
> It's actually unavoidable to store real passwords in cloud apps, as
> there is no trust or delegation model between services (that matter)
> which is usable or widespread enough to "just work". It doesn't seem to
> be for lack of effort though, as uncountably many companies and
> standards have been involved.
>
> It's probably too low-tech to suit most folks, but I'd like to see a
> cloud service created which does the following:
>

> * stores my ids/passwords in a way where I have a reasonable


> expectation it won't be compromised

> * provides an id/password on demand to anyone who a) asks for it,

randall

unread,
Sep 6, 2008, 12:40:54 AM9/6/08
to Cloud Computing
Hey Michael,

First I want to commend you on your rapid response on this issue.
Moving quickly to respond to and fix these issues is important. Now
for the bad part.

If passwords have always been stored via one-way hash, how did Shane
get his actual password back?

Also, I know the web chats I've used always ask if I want a transcript
emailed to me. I was once asked to give my password in one of these
chats and thought it very odd and would not do it, because these
emailed transcripts are sometimes sent over the wire in plain text or
cached on the smtp server or thick clients. So there are still holes
even if the web sessions are all SSL.

- randall

Shane Jones

unread,
Sep 6, 2008, 12:03:00 PM9/6/08
to Cloud Computing
The customer support rep that I spoke with said that the passwords
were encrypted, but not 1-way hash encrypted. They had an internal
tool that could lookup customer records and decrypt their password if
needed. He didn't mention the exact encryption method used.

Michael, thanks for your blog post and fast action on the issue. Your
open communication about this issue builds confidence that the GoGrid
team takes this seriously and isn't trying to sweep it under the rug.

-shane

Oscar Koeroo

unread,
Sep 6, 2008, 2:27:21 PM9/6/08
to cloud-c...@googlegroups.com
Hi Randall,

I'd like to note that if the one-way encryption of the password is MD5,
then I can be patient or look it up on a database by people who have
been patient for me. To me, that's not a security advertisement worth
noting. The security mechanisms and procedures you expose should be a
base line example.

Another weakness is the procedure of the password retrieval or reset
procedure. Telling the right stuff provides new keys to the kingdom.

Working with certificates might be a lot of extra hassle but could add a
new level of trust. If you're not up to the task to work the certificate
CA jazz yourself, then you can leave that to existing commercial CAs. If
the CAs do their job (except just collect $200 and sign a certificate
request by comparing bank transfer info or credit card info) then they
have a very well known identity relationship established between them
(the CA) and your customer. Other options, like GSI, might then also
become possible.


my 2 cts,

Oscar

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Cloud Computing" group.
> To post to this group, send email to cloud-c...@googlegroups.com
> To unsubscribe from this group, send email to
> cloud-computi...@googlegroups.com
> To post job listing, send email to jo...@cloudjobs.net (position title, employer and location in subject, description in message body) or visit http://www.cloudjobs.net
> For more options, visit this group at
> http://groups.google.ca/group/cloud-computing?hl=en?hl=en
> Posting guidelines:
> http://groups.google.ca/group/cloud-computing/web/frequently-asked-questions
> To collaborate in group's Wiki (http://sites.google.com/site/cloudcomputingwiki/) send request to cloudmo...@gmail.com
> -~----------~----~----~----~------~----~------~--~---

Pedro Soria-Rodriguez

unread,
Sep 6, 2008, 5:30:52 PM9/6/08
to cloud-c...@googlegroups.com
Indeed, using SSL is the easy and straightforward part.  
The difficult (and more important) part is the security management.  This means procedures, processes, and support systems in place to ensure access to information is only available to those who should have access.   
It is true that if someone at support had access to passwords, this shows that internal processes are (were?) not existent, not defined or not implemented.  Moreover, password were indeed not stored via one-way hashes. 
The security of the services over the internet may be very good (SSL) but this implies nothing about the internal workings of an organization.    Security encompasses all, not just the link between a client's web browser and the server.

--
Pedro Soria-Rodriguez, CISSP
sor...@gmail.com

Eric Kuzmack

unread,
Sep 7, 2008, 10:08:34 PM9/7/08
to Cloud Computing
Many LDAP directories provide exactly the sort of security that cloud
applications require. Using Novell eDirectory as an example, it
provides massive scalability, performance and security. It has all the
needed password management and self-service capabilities and provides
the ability to store the password with non-reversible encryption.

It supports all sorts of authentication methods including username/
password, certificate, multi-factor, etc....

Eric
> > > Twitter:www.twitter.com/cloudramp-Hide quoted text -

randall

unread,
Sep 8, 2008, 1:35:13 AM9/8/08
to Cloud Computing
Or something like Shibboleth for passing credentials around the cloud.

http://en.wikipedia.org/wiki/Shibboleth_(Internet2)

- randall
> > > > Twitter:www.twitter.com/cloudramp-Hidequoted text -

Oscar Koeroo

unread,
Sep 8, 2008, 12:31:16 PM9/8/08
to cloud-c...@googlegroups.com
Hi,

Shibboleth will give you federated identity-based authentication and
authorization infrastructure based on SAML. You still have the issue of
hosting an IdP and vetting the identities. This is to get the
credentials of the users into the SAML statements.

The technology is irrelevant for the procedures that should be done to
get identity handling deployed in a trustworthy and secured way.

The other thing is the federated 'thingy' about the technology. Usually
LDAP might be used for simple user base authenticated behind the IdP.
Employing the federated trust between the IdPs (= between domains) is
the thing that this technology is for.

IMHO: This doesn't seem to be the technology your looking for here...


cheers,

Oscar

Rich Wellner

unread,
Sep 8, 2008, 2:35:53 PM9/8/08
to cloud-c...@googlegroups.com
Oscar Koeroo wrote:
> Hi,
>
> Shibboleth will give you federated identity-based authentication and
> authorization infrastructure based on SAML. You still have the issue of
> hosting an IdP and vetting the identities. This is to get the
> credentials of the users into the SAML statements.
>

One of the advantages of federated security (ala shib, gsi or if you
combine them gridshib) is that the rules for vetting identities can be
managed locally.

So, in the example that started this thread, GoGrid wouldn't have had
access to the users authentication data.

rw2

Oscar Koeroo

unread,
Sep 9, 2008, 3:26:09 AM9/9/08
to cloud-c...@googlegroups.com

That's correct. I think the sysadmin department doesn't want to link
their user account database to a federated identity system just yet.
Some might do it though. Especially when there is a mutual benefit
between domains to start work on the federation. I wouldn't rule it out,
but in the given use case not very likely and useful.


Oscar

Rich Wellner

unread,
Sep 9, 2008, 9:12:06 AM9/9/08
to cloud-c...@googlegroups.com
Oscar Koeroo wrote:
Rich Wellner wrote:
  
Oscar Koeroo wrote:
    
Hi,

Shibboleth will give you federated identity-based authentication and 
authorization infrastructure based on SAML. You still have the issue of 
hosting an IdP and vetting the identities. This is to get the 
credentials of the users into the SAML statements.
  
      
One of the advantages of federated security (ala shib, gsi or if you 
combine them gridshib) is that the rules for vetting identities can be 
managed locally.

So, in the example that started this thread, GoGrid wouldn't have had 
access to the users authentication data.

rw2
    
That's correct. I think the sysadmin department doesn't want to link 
their user account database to a federated identity system just yet. 
Some might do it though. Especially when there is a mutual benefit 
between domains to start work on the federation. I wouldn't rule it out, 
but in the given use case not very likely and useful.
  

Agreed, there are institutional barrier (to put it nicely).

rw2

Reply all
Reply to author
Forward
0 new messages