Thursday Oct 31, 2013

What's New in SGD 5.1?

Oracle announced the latest version of Secure Global Desktop (SGD) this week with 3 major themes:

  • Support for Android devices;
  • Support for Desktop Chrome clients; 
  • Support for Oracle Unified Directory.

I'll talk about the new features in a moment, but a bit of context first:

Oracle SGD - what, how and why? 

Oracle Secure Global Desktop is Oracle's secure remote access product which allows users on almost any device, to access almost any type application which  is hosted in the data center, from almost any location. And it does this by sitting on the edge of the datacenter, between the user and the applications:

Architecure

This is actually a really smart environment for an increasing number of use cases where:

  1. Users need mobility of location AND device (i.e. work from anywhere);
  2. IT needs to ensure security of applications and data (of course!)
  3. The application requires an end-user environment which can't be guaranteed and IT may not own the client platform (e.g. BYOD, working from home, partners or contractors).

Oracle has a a specific interest in this of course. As the leading supplier of enterprise applications, many of Oracle's customers, and indeed Oracle itself, fit these criteria.

So, as an IT guy rolling out an application to your employees, if one of your apps absolutely needs, say,  IE10 with Java 6 update 32, how can you be sure that the user population has this, especially when they're using their own devices? In the SGD model you, the IT guy, can set up, say, a Windows Server running the exact environment required, and then use SGD to publish this app, without needing to worry any further about the device the end user is using.

What's new? 

So back to SGD 5.1 and what is new there:

Android devices

Since we introduced our support for iPad tablets in SGD 5.0 we've had a big demand from customers to extend this to Android tablets too, and so we're pleased to announce that 5.1 supports Android 4.x tablets such as Nexus 7 and 10, and the Galaxy Tab.

Here's how it works, with screenshots from my Nexus 7: Simply point your browser to the SGD server URL and login;

Login Webtop

The workspace is the list of apps that the admin has deemed ok for you to run. You click on an application to run it (here's Excel and Oracle E-Business Suite):

E Business Suite

There's an extended on-screen keyboard (extended because desktop apps need keys that don't appear on a tablet keyboard such as ctrl, WIndow key, etc) and touch gestures can be mapped to desktop events (such as tap and hold to right click)

All in all a pretty nice implementation for Android tablet users.

Desktop Chrome Browsers

SGD has always been designed around using a browser to access your applications. But traditionally, this has involved using Java to deliver the SGD client component. With HTML5 and Javascript engines becoming so powerful, we thought we'd see how well a pure web client could perform with desktop apps. And the answer was, surprisingly well. So with this release we now offer this additional way of working, which can be enabled by a simple bit of configuration. Here's a Linux desktop running in a tab in Chrome.

Chrome

And if you resize the browser window, the Linux desktop is resized by SGD too. Very cool!

Oracle Unified Directory

As I mentioned above, a lot of Oracle users already benefit from SGD. And a lot of Oracle customers use Oracle Unified Directory as their Enterprise and Carrier grade user directory. So it makes a lot of sense that SGD now supports this LDAP directory for both Authentication and as a means to determine which users get which applications, e.g. publish the engineering app to the guys in the Development group, but give everyone E-Business Suite to let them do their expenses.

Summary

With new devices, and faster 4G networking becoming more prevalent, the pressure for businesses to move to a increasingly mobile enterprise is stronger than ever. SGD is good for users, and even better for IT. By offering the user the ability to work from anywhere, and IT the control and security they need, everyone wins with SGD.

To try this for yourself, download SGD 5.1 (look under Desktop Virtualization Products) from the Oracle Software Delivery Cloud or if you're an existing customer, get it from My Oracle Support.

 -FB 

Friday Sep 13, 2013

Controlled Application Deployment with Secure Global Desktop

SGD is great for users because it allows them secure remote access from almost anywhere and any device.

So from my home Mac or PC, I can bring up a browser, login and run the apps that the sysadmin has published to me on my SGD Workspace:

Workspace

This means I can get access to my business applications that are running in the data center. And when I have to dash off somewhere, I can continue from my iPad or my friends Windows laptop, rejoining the application session exactly where I left off. 

But SGD is great for administrators too, because it delivers complete control over which applications can be accessed by which users. This power works both ways in terms of:

  • Mass deployment of an application to a large group of users;
  • Precision deployment of an application to a specific group of users. 

Here's how:

Say I have created an application object in SGD which represents my E-Business Suite front-end and I now want to deploy this to all the guys in Sales. In my corporate directory I have a Sales group like this:

AD Users

 Then to assign my E-Business Suite object I use the SGD Administration Console to say that this app is assigned to the Sales Group:

Assignment

Then next time my Sales team log in they get the E-Business Suite application in the workspace and they can launch it easily:

E-Business Suite

 Now how long did that take? ;-)

- FB 

Tuesday Jun 12, 2012

Oracle Virtual Desktop Infrastructure

A lot of the recent blog entries here have been about Oracle VM VirtualBox, possibly the coolest personal desktop virtualization product known to man. Deploying VirtualBox on your PC or Mac lets you run many virtual desktops at the same time to one user, you.

But did you know that VirtualBox can also power an Enterprise-scale virtual desktop deployment too, delivering many desktops to many users? 

As part of another Oracle product, Oracle Virtual Desktop Infrastructure (VDI), VirtualBox can run your Windows, Linux or Solaris desktops on servers located in the datacenter. Oracle VDI orchestrates the whole deal by looking after :

  • creating or cloning the virtual desktops from a master template;
  • managing the lifecycle of the desktops (create, start, suspend, resume, stop, delete);
  • assigning which users get which desktops; 
  • delivering easy and fast access to these virtual desktops from almost any device, such as existing PCs or Macs, iPads, or specially designed Sun Ray client devices too;
  • load balancing and session management of all of this.

 Architecturally the solution looks something like this:

VDI Architecture

This is an increasingly hot area of the IT landscape, so the Fat Bloke has decided to create a new blog category (VDI) and dedicate a few blog entries to look into this in a bit more detail over the next few weeks.

Watch this space...

- FB 

Monday Jan 28, 2008

SGD 4.40.917

Part of the graphics subsystem of SGD is based on the X.org project. Well because of a security vulnerability there is a re-released version of SGD now available.

Version 4.40.917 is now available and includes 2 significant additions:

  1. The X.org security fixes.
  2. Support for Windows Terminal Services Session Directory.

This second is a feature that wasn't due to arrive until the next release but the team took the opportunity to include it as part of this rebuild.

This is good news, especially for people using a mixture of Sun Ray and non-Sun Ray clients.

-FB 


Tuesday Jan 08, 2008

Speeding up LDAP queries when using Web Authentication

Some time back we discussed how to speed up LDAP authentication when logging into SGD. In this tip, we simply recommended reducing the user attributes that we search in order to authenticate a user given the provided credentials.

Well, nice tip as it was, it only works when you are logging in directly to SGD (using built-in authentication) and doesn't help if you are using Web Server Authentication. e.g. you're using something to protect the /sgd URI for example, a simple mechanism like Apache basic http authentication (.htaccess), or something powerful like Sun's Java System Access Manager to protect access to the /sgd URI.

If you're doing this, you need to configure an additional bean in the SGD system. And, to preserve your sanity, Fat Bloke recommends always keeping them in step by configuring them together:

/opt/tarantella/bin/tarantella stop
/opt/tarantella/bin/tarantella config edit --thirdpartyldaploginauthority.properties-searchAttributes cn mail
/opt/tarantella/bin/tarantella config edit --searchldapla.properties-searchAttributes cn mail
/opt/tarantella/bin/tarantella start

Sorry not to have mentioned this earlier ;-)

-FB

Wednesday Dec 12, 2007

SGD 4.4 - Protecting the Administration Console

Fat Bloke was recently asked about hiding, or really protecting, the new SGD administration console so that administration could only be done from say certain locations.

Well, I guess one of the advantages of making the Administration Console a web application is that we can use the power of the web server to help with this.

There are a couple of ways of doing this but I guess a simple way is to use the Apache Location directive:

<Location /sgdadmin>
    Order Deny,Allow
    Deny from all
    Allow from 129.156.4.240
</Location>

For more info on how to drive this check the Apache doc.

-FB 

Tuesday Dec 11, 2007

SGD 4.4 - The Administration Console

One of the major differences between version 4.4 and previous versions is the new web-based Administration Console.
Hopefully this is easier to use than the older Object Manager and Array Manager whose functions have now been coalesced into the one new tool.

Fat Bloke's readers are smart enough to find their own way around this tool so there's no tour here, but here are a few little known facts about the new tool:

  1. The SGD Administration Console is a pure web application which runs under the bundled Apache Tomcat and is located in the filesystem at
    /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgdadmin.war
  2. It uses a Sun standard UI style shared by many other Sun infrastructure apps such as Directory Server, Identity Server, Sun Ray Server, etc.
  3. It picks up your locale from the browser. e.g. on Firefox this is set in the Preferences...General...Language box. (Hmmm, wonder why the webtop (/sgd) doesn't do this?)
  4. The underlying datastore layout changed to support the separation of:
    • applications
    • application servers
    • user information
    which means that when you upgrade to SGD 4.4 the install script reorganizes your ENS tree. To check this out, use a command line like this:
    /opt/tarantella/bin/tarantella object list_contents --name ""
    to traverse the ENS tree.
    Note that this also means that if you have scripts that create objects via the command line, their locations should be below the above top level OUs. e.g.
    /opt/tarantella/bin/tarantella object new_windowsapp --name "o=applications/cn=notepad" --width 800 --height 768 --depth 24 
    --appserv "o=appservers/cn=Windows Server 1" --icon notepad.gif --displayusing seamless
  5. It was developed using Netbeans and uses only the public web service interfaces (so you could build your own replacement if you don't like it :-) )

SGD 4.4 - Logging in, did something change?

Do you ever get that spooky feeling when you visit a place you've been before, but something is slightly different, and you can't put your finger on what has changed?
That's a bit like the login procedure for SGD 4.4.

In versions leading up to SGD 4.4, simply by hitting the http://servername/sgd URL you were delivered the SGD client in the form of a Java archive. This was before you had logged in.
Now with 4.4, you have to successfully login before you get the client.

If any of you have web applications that talk to SGD using its web services, this subtle change may mean you have to switch around a couple of calls. but this is covered on the SGD wiki

Monday Nov 19, 2007

SGD 4.4 just released.

News about the latest release.[Read More]

Wednesday Oct 17, 2007

Desktop Virtualization Podcasts

Sun is publishing a series of Desktop Virtualization Podcasts which are basically chat shows with different guests, talking about new developments in the space.

Check 'em out.

-FB

Monday Oct 15, 2007

Free SGD licenses for partners

A little known fact is that Partners of Sun that want to set up their own SGD server for demonstrations or internal use, can request free NFR (Not for Resale) license keys to do so.

If this is you, contact your local Sun partner manager to get a license key

-FB

Thursday Oct 11, 2007

SGD and VDI

Most of you may know this already but for those that don't, I thought I'd take a minute to explain a little about SGD and its place in the new VDI market....

Server Based Computing (SBC)

SGD was originally designed to allow people to run local and remote apps side by side in a hybrid desktop model. The remote applications were made to look like local ones (seamless windows), and behave like local ones (printing, filesystem access, audio, etc) but they were actually running on back end server platforms. And most SGD customers use multiple local and remote apps simultaneously, e.g. they'll have several windows open running a mix of Windows, Solaris, Linux, etc. apps

This approach solves issues of data security (lost laptops), manageability (apps live on servers in datacenter) and mobility (use any client from any network location). So administrators can decide which apps should be centrally located and which local on the users PC.

But what if you wanted to deliver not just the apps, but the whole desktop environment too? Well, some SGD users do this today when they publish a full Windows desktop or Gnome-session, say. But traditionally, these have been desktops delivered from Windows Terminal Servers or Solaris/Linux Servers. And the problem with Windows Terminal Server has been that some apps just don't work in a Windows server environment (e.g. they expect a unique IP address or global access to the registry/filesystem, because they were designed to run on a PC).

Virtual Desktop Infrastructure (VDI)

So what is usually meant by VDI is that the desktop environments (usually Windows desktop environments) are not running on servers, but running on Windows \*client\* OSes which are themselves running in individual virtual machines on a server. e.g. Windows XP or Windows Vista instances on, say, VMware ESX Servers.

This is interesting because those misbehaved apps now have a better chance of working because they are running on the platform for which they were designed, a Windows PC.

Now all we have to do is provide secure access to these desktops, and that's what SGD has been doing for years just like this...

SGD and VDI

So hopefully you can see that SGD is equally applicable for SBC and VDI.

One more thing: if the value you derive from SGD is proportional to the number of apps you access via it, should I pay as much when I use SGD in a VDI environment? After all I'm just delivering a single app - the Windows desktop.

Thankfully, those smart guys in Sun Marketing have delivered a new product for exactly this use case.

When you buy licenses for Sun xVM VDI Software you are allowed to use SGD or Sun Ray Software to deliver a single desktop environment per user.

-FB

Wednesday Sep 19, 2007

SGD Portlet released into the wild

For those portal types amongst you that would like your portal to be able to offer applications as well as information, you might be interested in the newly released SGD Portlet.

This is a JSR-168 Portlet that was developed by the SGD and Sun Portal Server team.

We've made available the war file and the source code too.

Enjoy!

-FB

Sunday Aug 19, 2007

There can be only one (port in a firewall)

In the last blog we explored how to make the connections secure, which is essential if you want to use SGD in a secure, remote environment where users are outside and apps are inside the corporate network boundary. But an equally important pre-requisite is to work "nicely" with firewalls.

Many organizations have a policy which allows ports 80 and 443 (http/https) to remain open. So can SGD operate over these ports or do we need to spend weeks with the Security guys convincing them to open up other ports?

The answer is that SGD can work entirely over a single port and this blog explains how.

SGD, or a component thereof, is made to sit on the external 443 port as shown in this diagram

Thru a magical technique, SGD can discover if the traffic arriving on the port is AIP or https traffic, without needing to decrypt the traffic, and is then able to forward the stream to the web server or the SGD server as it deems fit. In this way only one port needs to be opened in the firewall.

Here's how to set up SGD in this way:

  1. Set up the webserver to listen on localhost:443
  2. You'll need to edit the webserver configuration file /opt/tarantella/webserver/apache/\*/conf/httpd.conf and change the port it listens on from:
    Listen 443
    to...
    Listen 127.0.0.1:443

  3. Set up SGD to listen on external-dns:443
  4. # /opt/tarantella/bin/tarantella config edit --array-port-encrypted 443
  5. Tell SGD where to send non-AIP traffic
  6. # /opt/tarantella/bin/tarantella config edit --security-firewallurl https://127.0.0.1:443 
  7. Finally, restart the web server and the SGD server
  8. # /opt/tarantella/bin/tarantella webserver restart --ssl 
    # /opt/tarantella/bin/tarantella restart

And now you're only using one port. Voila!

-FB

Saturday Aug 18, 2007

Securing the connections between the client and SGD server

When you initially install SGD (at least all versions up to the time of writing which is 4.31) the SGD webserver listens on port 80 and the SGD server listens on port 3144. And the traffic between the client and the SGD server, both http and AIP is unencrypted.

So how do we secure the communications between client and server?

  1. First we need an X.509 certificate
  2. Normally you have to go can buy an X.509 certificate from people like Verisign. Being tight, Fat Bloke uses a little known feature of SGD, which is a "self-signed certificate". This certificate is useless in a production environment as it certifies nothing, but it is free :-) . To get a self-signed certificate you create a CSR (certificate signing request) as usual:
    # /opt/tarantella/bin/tarantella security certrequest --country US --state CA --orgname "Acme Widgets Ltd"
    ...and follow the instructions. But instead of sending this request off to Verisign, keep your money in your pocket and type:
    # /opt/tarantella/bin/tarantella security selfsign 
    ignore the warnings and move on...

  3. Start the SGD server in secure mode
  4. The self signed certificate has automatically been placed in the /opt/tarantella/var/tsp directory and is used by SGD when you start it up using secure connections:
    # /opt/tarantella/bin/tarantella security start 
    So now we have secure AIP connections on port 5307. But what about the web server connections?

  5. Start the web server in secure mode
  6. The webserver that is bundled with SGD (apache) has a preconfigured httpd.conf file that looks for certificates in the same place that SGD uses to store certificates. So all we need to do is start the webserver with ssl enabled:
    # /opt/tarantella/bin/tarantella webserver restart --ssl

So now our web traffic and AIP traffic are using ssl on ports 443 and 5307 respectively.

In the next blog, we'll see how we can refine this deployment to work wholly over 443.

-FB

About

Fat Bloke

Search

Categories
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today