February 1999T. Haupt, DATORR meeting1 Gateway System New Generation of WebFlow

February 1999 T. Haupt, DATORR meeting 1

Gateway System

New Generation of WebFlow


Gateway Objectives• To provide infrastructure

supporting development of problem solving environments– create user space– define problem– identify resources

• To provide seamless and secure access to remote resources– allocate resources– monitor resources

Ken Flurchick, http://www.osc.edu/~kenf/Gateway


Services User Modules

Back-End Resources

Front-End

Back-end services comprise Tier 3.

Tier 1 is a high-level front-end for visual programming

Distributed object-based, scalable, and reusable Web server and Object broker

Middleware forms Tier 2

Three-Tier Architecture

Services User Modules

Data FlowFront-End

Standard InterfacesOO

Front-End

Task Specification

Metacomputing Services

DATORR

Back-End Resources


Architecture of Gateway

Globus

DOM/XML


CORBA Based Middle-Tier

Mesh of WebFlow Serversimplemented as CORBA objects.

Each server provides specificservices and serves as a container

for user’s modules

Front End

Gatekeeper:AuthenticationAuthorization


Middle-Tier

SECIOP

Security ModelFront End Applet

https

authentication& authorization

Gatekeeper

delegation

Stakeholders

HPCC resources

GSSAPIGSSAPI

Layer 1: secure Web

Layer 2: secure CORBA

Layer 3: Secure access to resources

Policies defined by resource owners


Distributed Objects are less secure

• can play both client and server– in client/server you trust the server, but not clients

• evolve continually– objects delegate parts of its implementation to the other objects (also dynamically composed at

runtime). Because of subclassing, the implementation of an object may change over time

• interaction are not well defined– because of encapsulation, you cannot understand all the interactions between objects

• are polymorphic (ideal for Trojan horses!)

• can scale without limit – how do you manage access right to millions of servers?

• are very dynamic

CORBA security is built into ORB

Secure Communications

Authentication

ClientUser

Encryption Audit Authorization

Server

Encryption

Credentials

ObjectAdapter

Authentication

• A principal is authenticated once by ORB and given a set of credentials, including one or more roles, privileges, and an authenticated ID.

• An authenticated ID is automatically propagated by a secure ORB; it’s part of the caller context

Principal Credentials

Current

Client Server

set_credentials get_attributes

authenticate


Privilege Delegation

• No delegation– The intermediary uses its own credentials

• Simple delegation– The intermediary impersonate the client

• Composite delegation– The intermediary uses both

ClientTa

rget

Clie

nt

Targ

et

Clie

nt

Targ

et

Clie

nt TargetObject

IIOP

CORBA access model

• Based on a trusted ORB model:you must trust that your ORB will enforce the access policy on the server resource

• The ORB determines:if this client on - behalf of this principal - can do this operation on this object

• Server uses Access Control Lists (ACL) to control user access

Principal Role Rights Operation


Mary Thompson, http://www-itg.lbl.gov/security/Akenti/DOE2000/sld014.htm


User 1 User 2

Application 1

Application 2

App 2App 1

WebFlow Server

WebFlow server is given by a hierarchy of containers

and components

WebFlow server hosts users and services

Each user maintainsa number of applications

composed of custom modules

and common services

WebFlow Services

Initialization of a session

PortalPage

SecureWeb Server

Mutual

authenticationstart

AKENTI

CredentialsGlobus Cert.

Front EndApplet

WebFlowServer User

ContextNetscape’s ORB ORBacus ORBIIOP


Building an applicationApplet Application

Context

Netscape ORB ORBacus ORBIIOP

List of servers

List of modules

List of events

List of methods

E M

Add module

Attach Event

local remote

Adapter LLM


Event binding

addEventListenerrmEventListenerfireEvent(E,M)

method M

Event Source Event TargetAdapter

Event

ORB

binding table

DII DSI


WebFlow over Globus• In order to run WebFlow over

Globus there must be at least one WebFlow node capable of executing Globus commands, such as globusrun

• Jobs that require computational power of massively parallel computers are directed to the Globus domain, while others can be launched on much more modest platforms, such as the user’s desktop or even a laptop running Windows NT.

Bridge between WebFlow and Globus


Gateway Components

• Front End (Java Applets)– many different “plug-ins” implementing

WebFlow API• Middle Tier (CORBA)• Back End modules (anything from JBDC to HPF)

– JavaBeans model– Proxy Modules

• Access to remote HPCC resources

Documents

February 1999T. Haupt, DATORR meeting1 Gateway System New Generation of WebFlow