For example, if a local application calls up to a Force.com service, the identity of the client must flow up to the Force.com service. The pivot point which connects the local applications to the Cloud is an XML Gateway . If a user is using a local application, and that application is connecting to a Cloud-based service (e.g. to Amazon's S3 storage service), then that connection must be managed based on the identity of the user, not only based on the client application. The decision should not only be "is this application allowed to put data up into Amazon S3?", but "Is this particular user running this particular application allowed to put this particular data up onto Amazon S3?". This is the level of control which the Vordel XML Gateway Cloud Edition can provide. It becomes especially important if local applications are using other Cloud services from multiple providers (i.e. "identity in the clouds" not just "identity in the cloud").
Here, from the Open Group site, is a picture of clouds over London:
4 comments:
I always enjoy learning how other people employ Amazon S3 online storage. I am wondering if you can check out my very own
tool CloudBerry Explorer that helps to manage S3 on Windows . It is a freeware. . I would be very thankful if you mention it during your speech on Open Group practitioner conference - of course if you like it.
Thanks for the pointer Andy - I'll check out Cloudberry Explorer. Looks like a useful tool alright
cheers,
Mark
Interesting topic. I have been responding to this very question on and off especially in couple of forums and linkedin. This is a key topic that is often missed while planning for any Service Integration. My question is how do we get the message across to the development community or architects or application security specialists. Any thoughts?
I think the problem is that Cloud Computing usage is a pretty new thing now, and has a Wild West feel to it. Developers may naturally be excited to host an app, or part of an app, on an Amazon EC2 AMI, or make use of Amazon S3 for storage, etc. That's all great, exciting stuff. But the "identity in the cloud" piece is missing, because the connection to the Cloud infrastructure is sent under the context of one particular user (usually a developer token issued to a developer) rather than with any linkage to the end-user. There is no Single Sign On up to the cloud service, in other words.
That may not sound like a problem, but imagine if you want to retrace who accessed particular data which your company had stored using the Amazon S3 service. If you are merging all access down to that one developer ID, you don't have that audit trail which you can follow. However, if you use an XML Gateway as a kind of local "Gatekeeper" to the Cloud Services, you can keep that trail there (i.e. the Gateway authenticates the user, or uses a Kerberos or SAML token or SSO token to identify them if they have been authenticated already, and the Gateway then calls up to the Cloud Service on their behalf, keeping an audit trail of what it is doing).
I agree this message has to get across to developers and architects, that access to Cloud Services should be managed (or "governed"). I think that presenting clear scenarios and Use Cases is the best way.
Post a Comment