Since IBM Bluemix is build on top of Cloud Foundry, all the knowhow and tooling available for the later can be used in Bluemix too.
One of the tools I'm fond of is the Cloud Foundry command line cf. The tool is a thin veneer over the Cloud Foundry REST API and is written in GO. "Thin veneer" is a slight understatement, since the cf command line is powerful, convenient and - icing on the cake - extensible.
A list of current plug-ins can be found in the CF Plug-in directory. Now the installation instructions haven't kept up with the cf releases, so here are the steps you need:

1. Head to the CF Command Line release page and make sure you have the latest release installed.
   At time of this writing that would be 6.12.2
2. Add the community repository to your installation using this command:
   cf add-plugin-repo CF-Community http://plugins.cloudfoundry.org/
   This command is only available in cf versions > 6.10. A lot of blog entries or even the github documentation suggest downloads or even golang installs. With the availability of the repository these steps are no longer necessary (but you are free to use them)
3. Now listing all available plug-ins is as simple as cf repo-plugins
4. To install a specific plug-in you issue the command:
   cf install-plugin '[name of plugin as listed]' -r CF-Community
   If the name doesn't contain white space, the quotes can be omitted
5. After installation cf help provides the short instructions on how to use the modules

The interesting question now is, what are the plug-ins worthwhile looking at.

NodeRED has conquered a place in my permanent toolbox. I run an instance in Bluemix, on my local machine and on a Raspberry PI. I build a little demo where a light connected to a Particle lights up based on an event reaching a NodeRED instance. However I don't carry my IoT gear every time (got lots of funny looks at airport security for it), but I still want to demo the app. The NodeRED side is easy. I just added a websocket output node and the server side is ready to roll.

On the browser side I decided to use angular.js and one of its web socket libraries ng-websocket. The application code is just about 50 lines, so here it goes:

'use strict';

var websocketEndpoint = 'wss://'+window.location.hostname+'/ws/bulb';

console.log('Application loading ...');
// Declare app level module which depends on views, and components
var myApp = angular.module('myApp', ['ngWebsocket','ngRoute']);

myApp.config(['$routeProvider', function($routeProvider) {
    console.log('Routes loading... ');
    $routeProvider.when('/bulbon', {
        templateUrl: 'bulbs/bulb-on.html'
    }).when('/bulboff', {
        templateUrl: 'bulbs/bulb-off.html'
    }).when('/bulbunknown', {
        templateUrl: 'bulbs/bulb-unknown.html'
    }).otherwise({redirectTo: '/bulbunknown'});
}]);

myApp.run(function ($websocket, $location) {
    console.log('run');
    var ws = $websocket.$new({
        url: websocketEndpoint,
        reconnect: true
    }); // instance of ngWebsocket, handled by $websocket service

    ws.$on('$open', function () {
        console.log('Websocket connection open');
    });

    ws.$on('$message', function (data) {
        console.log('data arrived');
        console.log(data);
        var newlocation = '#/bulbunknown';
        if (data.bulb === 1) {
            newlocation = '#/bulbon';
        } else if (data.bulb === 0) {
            newlocation = '#/bulboff';
        }

        window.location = newlocation;
    });

    ws.$on('$close', function () {
        console.log('Websocket connection closed');
    });
});

console.log('Done');

##
The HTML is simple. I split it into the main file and 3 status files. One could easily put the statuses into a script template section or inside the app This would reduce the number of http requests. For the bulb I used font-awesome, so no image has been harmed in creating this demo.

The bower.json

{
  "name": "iotlightbulb",
  "description": "A simple lightbulb show from a websocket",
  "version": "0.1.0",
  "license": "APACHE2.0",
  "private": true,
  "dependencies": {
    "angular": "~1.4.0",
    "angular-route": "~1.4.0",
    "html5-boilerplate": "~5.2.0",
    "ng-websocket": "~0.2.1",
    "components-font-awesome": "components/font-awesome#~4.3.0"
  }
}

index.html

<!DOCTYPE html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>The Socket bulb</title>
    <meta name="description" content="">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="stylesheet" href="bower_components/html5-boilerplate/dist/css/normalize.css">
    <link rel="stylesheet" href="bower_components/html5-boilerplate/dist/css/main.css">
    <link rel="stylesheet" href="bower_components/components-font-awesome/css/font-awesome.min.css">
    <link rel="stylesheet" href="app.css">
    <script src="bower_components/html5-boilerplate/dist/js/vendor/modernizr-2.8.3.min.js"></script>
</head>
<body ng-app="myApp">
<div class="container">
<!--[if lt IE 9]>
<p class="browsehappy">You are using an <strong>outdated</strong> browser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your experience.</p>
<![endif]-->
<h1>Angular Lightbulb App</h1>

<div ng-view>Let there be light</div>
<ul class="menu">
<li><a href="#/bulbunknown">unknown</a></li>
<li><a href="#/bulbon">ON</a></li>
<li><a href="#/bulboff">OFF</a></li>
</ul>
</div>
<script src="bower_components/angular/angular.js"></script>
<script src="bower_components/angular-route/angular-route.js"></script>
<script src="bower_components/ng-websocket/ng-websocket.js"></script>
<script src="app.js"></script>
</body>
</html>

bulb-unknown.html

<p>The light <br/>
    <span class="fa-stack fa-5x">
        <i class="fa fa-lightbulb-o  fa-stack-2x" style="color :  #000044"></i>
        <i class="fa fa-question-circle fa-stack-1x" style="color :  red"></i>
    </span>
</p>

bulb-on.html

<p>The light <br/>
    <span class="fa-stack fa-5x">
        <i class="fa fa-cog fa-stack-2x" style="color :  yellow"></i>
        <i class="fa fa-lightbulb-o  fa-stack-2x" style="color :  #FFAB00"></i>
    </span>
</p>

bulb-off.html

<p>The light <br/>
    <span class="fa-stack fa-5x">
      <i class="fa fa-ban fa-stack-2x" style="color: red;"></i>
        <i class="fa fa-lightbulb-o  fa-stack-2x"> </i>
    </span>
</p>

The CSS

/*app css stylesheet*/
.container {
  margin : 25%;
  width : 50%;
  text-align: center;
}

.menu {
list-style: none;
border-top: 0.1em solid black;
margin-top: 2em;
padding: 0 0 0.5em;
}

.menu:before {
content: "[";
}

.menu:after {
content: "]";
}

.menu > li {
display: inline;
}

.menu > li:before {
content: "|";
padding-right: 0.3em;
}

.menu > li:nth-child(1):before {
content: "";
padding: 0;
}

As usual: YMMV

Who is using your application and what they can do has evolved over the years. With cloud computing and the distribution of identity sources, the next iteration of this evolution is pending. A little look into the history:

• In the beginning was the user table (or flatfile) with a column for user name and (initially unencrypted) password. The world was good, of course only until you had enough applications and users complaint bitterly
• In the next iteration access to the network or intranet was moved to a central directory. A lot of authentication became: if (s)he can get to the server, we pick up the user name
• Other applications started to use that central directory to look up users, either via LDAP or propriety protocols. So while the password was the same, users entered it repeatedly
• Along came a flood of single sign-on frameworks, that mitigated identity information between applications, based on a central directory. Some used an adapter approach (like Tivoli Access Manager), others a standardised protocol like LTPA or SPNEGO

All of these have a few concepts in common:

• All solutions are based on a carefully guarded and maintained central directory (or more than one). These directories are under full corporate control and usually defended against any attempt to alter or extend the functionality. (Some of them can't roll back schema changes and are build on fragile storage)
• Besides user identity they provide groups and sometimes roles. Often these roles are limited to directory capabilities (e.g. admin, printer-user) and applications are left to their own devices to map users/groups to roles (e.g. the ACL in IBM Notes)
• The core directory is limited to company employees and is often synchronised with a HR directory. Strategies for inclusion of customers, partners and suppliers tend to be point solutions

In a cloud world this needs to be re-evaluated. The first stumbling block are multiple directories that are no longer under corporate control. Customer came to expect functionality like "Login with Facebook" and security experts are fond of two factor authentication - something the LDAP protocol has no provision for. So a modern picture looks more like this:
<

Core tenants of Identity

• An Identity Provider (IdP) is responsible to establish identity. The current standard for that is SAML, but that's not the only way. The permission delegation known as OAuth, to the confusion of many architects, can be used as authentication substitute (I allow you to read from my LinkedIn profile my name and email via OAuth and you then take that values as my identity). In any case, the cloud applications shouldn't care, they just ask the respective service "Who is this person?". Since the sources can be very different, that's all he SSO will (and shall) provide
• The next level is the basic access control. I would place that responsibility on the router, but depending on cloud capability each application needs to check itself. Depending on the security need an application might show a home page with information how to request access or deflect to an error (eventually hide behind a 404). In a micro service world an application access service could provide this information. A web UI could also use that service to render a list of available applications for the current user
• It is getting more interesting now. In classical application any action (including reading and rendering data) is linked to a user role or permission. These permissions live in code. In a cloud micro service architecture the right to action is better delegated to a rule service. This allows for more flexibility and user control. To obtain a permission a context object is handed to the rule service (XML or JSON), that in its bare minimum contains just the user identity. In more complex cases it could be value, project name, decision time etc. The rule engine then approves or denies the action
• A secondary rule service can go an lookup process information (e.g. who is the approver for a 5M loan to ACME Inc). Extracting the rules from code into a Rule Engine makes it more flexible and business accessible (You want to be good at caching)
• The rule engine or other services use a profile service to lookup user properties. This is where group memberships and roles live.
  One could succumb to the temptation to let that service depend on an LDAP corporate directory, only to realise that the guardians will lock him down (again). The better approach is the profile service synchronises properties that are maintained in other systems and presents the union of them to requesting applications
• So a key difference between the IdP and the profile service: the IdP has one task and one only, it performs that through lookups. The profile service provides profile information (in different combinations) that it obtained through direct entry or synchronisation
• The diagram is a high level one, the rule engine and profile service might themselves be composed of multiple micro services. This is beyond this article

Another way to look at it is the distinction between Who & What

As usual YMMV