Identity Touch Points - Applications Architecture Perspective

Identity Management is a mature IT concept and is the foundation of good security and solid regulatory compliance. Today, with the paradigm shift in cloud computing and mobility era, businesses need to understand and prepare their IT organizations to enable or associate user's identity and entitlements, and extend access privileges beyond the traditional corporate perimeters. This change is introducing new risks and it is also prompting new questions about ownership and control of digitized information.

However, what do the services/applications consider to be the attributes that define user/businesses unique identity? From a technology standpoint, I see identity products to be broadly classified into 3 pillars based on their feature offerings/solutions:

1) Identity Governance

User/Entitlement provisioning, Password/Profile management, Self-service Access/Roles catalog management

2) Access Management

Single sign-on, Authorization, Authentication

3) Identity Platform Services
Policy Compliance and Enforcement, Security Stores, Replication, Synchronization

Mapping these core identity functions/features into the enterprise application architecture space is quite challenging. In reality, our understanding of a business entity (person/tenant/business) identity is built upon an incomplete set of attributes that the application/service architecture deems sufficient to differentiate one entity from another. But this attribute set is generally far from complete and  a wide range of perceptions exist regarding what is considered acceptable to uniquely define an entity's identity in the application/service domain. Application architecture must accept a level of risk and be willing to offer service on the basis that a business/user's identity definition is "good enough" for the purpose of which the application/service is going to use it.

Here is my attempt at capturing the high-level identity touch points that matter to the application-architecture design across the enterprise technology domain. 

Converting OVA file for use with Oracle VM Server Xen Commands

Recently, my team received a OVA file (VBX_Image_from_customer.ova) - a customer instance image to validate SOA Suite environment upgrade in-house. It would have been much easier to import the appliance into the Virtual Box on our local env (laptop/desktop) and get going. However, we had to host the appliance internally for cross-development and QA teams, and the only dedicated hardware at our disposal was a Oracle VM Server 3.2 physical machine.

Basically, the problem was two-fold:
a) OVA file cannot be specified as a disk parameter in the Oracle VM template configuration vm.cfg
b) Virtual Box cannot be installed on a Oracle VM Server machine (because Virtual Box can't operate under another hypervisor)

In this write-up, I will share the main tasks executed to use the ova file and create the guest virtual machine on the OVM Server host.   The OVA (Open Virtual Appliance) file is nothing more than a TAR archive, containing the .OVF and .VMDK files. For those interested, here is a good post by Mike on the different file formats and tools for virtualization.

-- Install disk image conversion utility
# yum install kvm-qemu-img.x86_64

-- Extract the OVA file contents
# tar -xvf VBX_Image_from_customer.ova
# ls
    - VBX_Image_from_customer-disk1.vmdk
    - VBX_Image_from_customer.ovf

-- Determine if your version of QEMU supports VMDK Sparse by executing the following command
# qemu-img info VBX_Image_from_customer-disk1.vmdk

-- if you get a message like below then VMDK Sparse is not supported
<<qemu-img: Could not open 'VBX_Image_from_customer-disk1.vmdk'>>

-- Use the VBoxManage command-line tool that ships with VirtualBox (if qemu-img option does not work)
# VBoxManage clonehd VBX_Image_from_customer-disk1.vmdk --format RAW developmentSOA.img

-- Convert from vmdk to raw img if your version of QEMU supports VMDK Sparse
# qemu-img convert -f vmdk -O raw VBX_Image_from_customer-disk1.vmdk developmentSOA.img

-- Use the RAW image file in the vm.cfg 'disk' parameter; sample file below

bootloader = '/usr/bin/pygrub'
device_model = '/usr/lib/xen/bin/qemu-dm'
disk = ['file:<path-to-OVS-repository>/developmentSOA.img,hda,w']
memory = '8192'
maxmem = '8192'
OVM_simple_name = 'MyCompany SOA V2'
name = 'SOA_V2_MYCOMP'
OVM_os_type = 'Oracle Linux 5'
vcpus = 4
uuid = 'e405f7ea-80bb-4a14-97b2-cf969077e25a'
on_crash = 'restart'
on_reboot = 'restart'
keymap = 'en-us'
vnc = 1
vncconsole = 1
vnclisten = '127.0.0.1'
vncpasswd = ''
vncunused = 1
vif = ['bridge=xenbr0']
timer_mode = 2
expose_host_uuid = 1

-- Create VM guest instance using Xen command
# xm create vm.cfg -c

You should be all set to start up the customer guest virtual machine.

Quick Setup of OpenStack Icehouse Development Env on Ubuntu14

OpenStack - there are quite a lot of vendors (including large enterprises) gravitating around the OpenStack ecosystem. It is a good thing that there is ample competition, which means more options for customers and hopefully better business models driving the cloud enterprise market. I look forward to research more from a technical standpoint.

In my view, a good starting point to learn more about the different technical features in OpenStack, is to experiment with them on a  small scale local environment. My test bed is a Ubuntu 14.4 64-bit Linux system on a 8x Intel Xeon CPU machine, with 8G memory and two physical network interface cards. The goal is to basically setup an all-in-one configuration, where all the services, including compute services, are installed on the same node. A controller node is where most of the OpenStack services are configured, and will be installed on my Ubuntu system.

Here, I will discuss couple of quick OpenStack development environment setup options:
    a) Using stable Git Icehouse repository
                OR
    b) Using Vagrant Box

Option-A:  Deploy OpenStack IceHouse using Git repo

1. Create work directory for OpenStack project, say $ICE_STACK_DIR
 
    # mkdir /scratch/<user>/icehouse  

2. Clone stable/icehouse git repository

   - used Netbeans ide to clone the Git repository branch to workdir location; alternately, run the following command from $ICE_STACK_DIR
 
    # git clone -stable/icehouse https://github.com/openstack-dev/devstack.git
   
3. Modify Devstack configuration file to override default settings as needed

  - localrc is a user-maintained settings file used to configure DevStack. It is deprecated and has been replaced by local.conf. More details here

  Sample local.conf: 



4. Install DevStack as a non-root user

   # cd $ICE_STACK_DIR/devstack
   # ./stack.sh

  - Read more about the stack.sh script in the official documentation

 - The default services configured by DevStack are Identity (Keystone), Object Storage (Swift), Image Storage (Glance), Block Storage (Cinder), Compute (Nova), Network (Neutron), Dashboard (Horizon)

  - During install run, hit errors like below:
        cp: cannot create regular file '/etc/nova/policy.json': Permission denied
     
    the resolution was to basically edit the file work-dir/devstack/lib/nova and change to 'sudo cp' for the failing file-access occurrences; for e.g. the following changes were made

        sudo cp -p $NOVA_DIR/etc/nova/policy.json $NOVA_CONF_DIR

        # Get the sample configuration file in place
        sudo cp -p $NOVA_DIR/etc/nova/api-paste.ini $NOVA_CONF_DIR
        sudo chown $STACK_USER $NOVA_CONF_DIR

   - To give an estimate, deploying DevStack in  my environment took between 5-6 minutes (after prior multiple failed attempts)

5. Perform basic sanity tests

   - Run the test scripts
         # cd $ICE_STACK_DIR/devstack/tests
         # ./functions.sh
         # ./test_config.sh
   
   - Run the exercise scripts
        # cd $ICE_STACK_DIR/devstack/exercises
   
       # ./horizon.sh 
   
        -- expect to see something like the following message printed on the console if everything goes well with the deployment
        .............
        + set +o xtrace
        *********************************************************************
        SUCCESS: End DevStack Exercise: ./horizon.sh
        *********************************************************************

6. Launch OpenStack Horizon Dashboard

   - Go to URL http://my.eth1.ipv4.address
   - Logon as default user 'demo' or 'admin' and password $ADMIN_PASSWORD set in local.conf

   Here is a screenshot of the dashboard System Info panel

7. Try creating instances from the Dashboard

   - Refer OpenStack Admin Guide for more details on managing the resources and services using the Horizon dashboard    

8.  Stopping and Restarting DevStack

   - To stop all processes that were started by stack.sh
        # cd $ICE_STACK_DIR/devstack
        # ./unstack.sh
   
   - To restart DevStack
        # cd $ICE_STACK_DIR/devstack
        # ./rejoin-stack.sh

Option-B. Deploy DevStack Icehouse using Vagrant

I found this blog article 'OpenStack Cloud Computing Cookbook' by Kevin very helpful in setting up my local development environment virtual machines.

Installed the following:

1. VirtualBox 4.3.10
2. Vagrant 1.4.3
3. Vagrant Cachier plugin    
     
and then followed the instructions as-is, they just work as documented.

Hoping to share my experiments with OpenStack as I learn more ....

Creating logical partition on Exalogic X3-2 ECHO vServer using LVM

I switched to using the recently announced Exalogic X3-2 Echo (2.0.6.0.0) guest template for packaging the application software VM. However, on trying to increase the disk space as in the Navstar (2.0.4.0.0) template version using the modifyjeos tool (version 1.1.0-17), I ran into the the following error:

# modifyjeos -f System.img -P App.img 6144 /u01 -S 2048 -n EL_ECHO_MYAPP_2.0_VM_TEMPLATE
Starting VM image reconfiguration...
ERROR: Unknow filesystem.

No detailed messages other than the single line below were logged to /var/log/modifyjeos.log
       ...modifyjeos version 1.1.0-17 starting
 
I later learnt that modifyjeos does not support LVM and this is one of the new feature in Exalogic ECHO (2.0.6.0.0) release. Using Logical Volume Manager (LVM) is recommended to increase/create the virtual disk space. Here are the steps followed to prepare the Exalogic Echo guest VM instance for creating a logical partition to host the application software.


Refer the official Exalogic X3-2 Elastic Cloud Administrator's Guide "Managing LVM Partitions on Guest vServers" for more details on this subject

Creating Application VM Templates for Exalogic X3-2

 It is a well known fact that one of the primary goal for applications virtualization is to provide enterprise users with a consistent and reliable experience through accelerated deployment. For complex enterprise-class applications like Oracle SOA Suite (or IdM/any other business software), virtualization facilitates rapid provisioning and delivery of optimized application configuration to meet security, high availability and performance standards.

Exalogic Elastic Cloud X3-2 is Oracle' flagship engineered system for running business applications in a highly performant environment. The Exalogic X3-2 software includes a optimized Exabus­ enabled Type I Xen hypervisor i.e. Oracle VM Server, which allows to host virtual servers running Oracle Linux. In this post, I will share my experience creating an application template for deploying on Exalogic.

The application template creation procedure for Exalogic can be split into 2 broad categories:

1. Preparing the Oracle VM Server environment
2. Creating the application VM template

Note that access to an Exalogic instance is not required for the purpose of creating the application templates.You will require the following software though; download from eDelivery.oracle.com

• "Oracle Linux JeOS for Building Oracle VM Templates Media Pack v13 for x86_64 (64 bit)"
• "Oracle Exalogic 2.0.4.0.0 Base Guest Template" for Exalogic Linux x86-64 (64 bit) V35512-01  (requires OVM Server 3.x or later)

First, the steps to configure the Oracle VM Server:

1) Connect to Oracle VM Server 3.x
- it is recommended to use VM Server 3.x installation or later
- ssh username@hostname

2) Configure xend-config.sxp on the OVM Server (OVS) to use bridge networking
- the OVS system must be setup so that we can attach virtual machines to the external network. This is done by creating a virtual switch within dom0 (domain zero i.e. management domain in a OVS env responsible for hardware detection) that takes packets from the virtual machines and forwards them onto the physical network so they can see the internet and other machines on your network. The piece of software we use to do this is called the Linux bridge and its core components reside inside the Linux kernel. In this case the “bridge” is effectively our virtual switch.

# vi /etc/xen/xend-config.sxp
(network-script network-bridge)
(vif-script vif-bridge)

3) Restart OVM Server
# [root@ovmserver BASE]# reboot

4) Configure your OVM Server operating system to use a public Yum repository
- download and install any prerequisite Oracle Enterprise Linux packages not installed on your computer from the public Oracle Yum repository

--- Oracle Linux 4, Update 6 or Newer
# cd /etc/yum.repos.d
# mv Oracle-Base.repo Oracle-Base.repo.disabled
# wget http://public-yum.oracle.com/public-yum-el4.repo

--- Oracle Linux 5
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-el5.repo

--- Oracle Linux 6
# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ol6.repo

5) Install the JeOS dependent packages with the following command:
# yum install createrepo

6) Install "Oracle Linux JeOS for Building Oracle VM Templates Media Pack v13 for x86_64 (64 bit)"
     - JeOS is particularly useful and handy when you need to re-size the VM template Root Disk Image
- download the zip files for JeOS base and JeOS base image for required operating system to your OVS system in local directory e.g /u01/JeOS.
        (you will have following rpms in your local directory after uncompressing the zip files)
ovm-modify-jeos-1.1.0-17.el5.noarch.rpm
ovm-template-config-1.1.0-8.el5.noarch.rpm
ovm-el5u8-xvm-jeos-1.1.0-2.el5.x86_64.rpm

- install these rpms

# rpm -ivh ovm-modify-jeos-1.1.0-17.el5.noarch.rpm
# rpm -ivh ovm-template-config-1.1.0-8.el5.noarch.rpm
# rpm -ivh ovm-el5u8-xvm-jeos-1.1.0-2.el5.x86_64.rpm

7) At the end of this step, you will have the base OVM Server environment ready to create the virtual machines (or virtual host servers in Exalogic terminology).

Next, the steps to create the application VM template. Three main phases:

1. Creating VM using Exalogic Base Guest template  
2. Installing and configuring the required application software
3. Preparing the VM template TAR

Phase1

1. From eDelivery.oracle.com download "Oracle Exalogic 2.0.4.0.0 Base Guest Template" for Exalogic Linux x86-64 (64 bit) V35512-01 

2. Extract the Exalogic Guest Template contents to a directory location (say /Exalogic/BASE) on your Oracle VM Server 3.x installation

    # ssh username@ovshostname
     # mkdir -p /Exalogic/BASE
      
    # pwd
   /Exalogic/BASE
   
    BASE]# ls
    System.img  vm.cfg 
    
3. Change the path to the virtual disk in the vm.cfg file, as follows:
        disk = ['file:/OVS/seed_pool/OVM_simple_/System.img,hda,w'] to disk = ['file:/Exalogic/BASE/System.img,hda,w']  

4. In the Exalogic Guest template vm.cfg file, set vif = ['bridge=bond0'], where bond0 is the bridging Ethernet adapter on OVS. It is usually called 'xenbr0'

5. Start the VM with '-c' flag, and press Ctrl+D when it gets to the OVM template configuration stage
# cd /Exalogic/BASE
# xm create vm.cfg -c  
       (alternatively, you can skip the '-c' flag and connect to the VM using the command: xm console <vm-
         domain-Id>)

6. Login as 'root' to the created VM host (lets call it App-VM)
      - the default root password is 'ovsroot'

7. Add the network script ifcfg-eth0 in the App-VM 
- if eth0 already exists, use a different one
      - there are two options, DHCP, and Static IP Address. If you choose to make use of DHCP to automatically assign IP addresses to servers or virtual machines within a network, you must ensure that a DHCP server is set up and available within your VM environment

 # vi /etc/sysconfig/network-scripts/ifcfg-eth0
-----------------------------------------
DEVICE=eth0
            BOOTPROTO=static
            ONBOOT=yes
            IPADDR=10.200.250.300
            NETMASK=255.255.252.0
            GATEWAY=10.200.220.320
            DELAY=0

8. Configure the Network
- Edit the host name in the App-VM /etc/sysconfig/network file
- Edit the host name in /etc/hosts/
- Update /etc/resolv.conf as well

9. Turn off the initial configuration of the OVM template
# vi /etc/sysconfig/ovmd
set INITIAL_CONFIG=no

10. Use ifup to bring eth0 online or reboot VM
# /sbin/ifup eth0

11. Restart the networking service
# /etc/init.d/network restart

Phase2

1. Copy the necessary application software to the App-VM environment created in phase1
- you may need to configure the required JDK as well if your application depends on it. Exalogic guest template OS does not package any Java runtime
2. Install and configure the business applications in the App-VM

Phase3

1. Prepare to create a Template from the running App-VM
- Update ovmd script

# vi /etc/sysconfig/ovmd
Set the "INITIAL_CONFIG" parameter to "yes"
INITIAL_CONFIG=yes

2. Cleanup App-VM host specific OS-network level configuration
- Remove DNS information
    - Remove extraneous SSH information
    - Cleanup network file
# cd /etc/sysconfig
# sed -i '/^GATEWAY/d' network
    - Cleanup hosts file
    - Remove networking information
# cd /etc/sysconfig/network-scripts
# rm -f ifcfg-*eth*
# rm -f ifcfg*ib*
# rm -f ifcfg*bond*
     
# cd /etc/sysconfig/networking/profiles/default
# rm -f ifcfg-*eth*
# rm -f ifcfg*ib*
# rm -f ifcfg*bond*
    - Remove logs
    - Remove kernel messages
# cd /var/log
# rm -f dmesg
# dmesg -c
    - Remove history
# rm -f /root/.bash_history
# history -c

(Note: execute steps 3 through 5 below from the OVM Server host)

3. Shutdown App-VM

# xm list
# xm shutdown <VM_ID>

4. Compact the App-VM template vDisks (optional)

# [root@ovmserver BASE] modifyjeos -f System.img -zero-out-all 

5. Package the vServer with its virtual disk

# tar -pczvf <app_template_name>.tgz <el_base_template_directory>

The TAR VM template <app_template_name>.tgz is now ready to be uploaded/deployed to the Exalogic Elastic Cloud

Hope this helps to get a general idea on what it takes to create application templates on Linux for Exalogic X3-2 system. Feel free to share your experience/comments/tips .