Interoperable Portal Services by amberp


									Interoperable Portal Services

         Marlon Pierce
      Community Grids Lab
       Indiana University
               Project: ET011
• Goals of the project are to demonstrate
  interoperability between Portal/PSE projects
   – Mary Thomas (PI), TACC: HotPage
   – Tomasz Haupt, MSU: DMEFS
   – Marlon Pierce, IU: Gateway
• We are building interoperability at two levels:
   – Web services provide standard interfaces
   – Portlets provide component-based interfaces
                     Portal Security
• We are building off Gateway’s                      Browser
  approach for Web-based
  security for DOD portals.                                     HTTPS
    – Approved for ARL and ASC
• Users kinit to a web server to
  get a ticket.                         DMZ             Web
    – SSL, MD’d sessions,
      Certificates maintain secure                     Server
    – Web server typically located in
      “DMZ”                             krcp, krsh
• Web server manages session
  IDs, invokes backend requests
  with Kerberos client utilities.                HPC            HPC
         Portlets and Containers
• One of the problems of previous portal development is that
  there is no good way to share interface components.
   – How do developers share web interfaces?
• Also, how can we avoid constantly reinventing things like
  login services, customization services, page organization,
  access controls.
• Answer: use portlets and containers.
   – Becoming a recognized best practice for portal development
     because it enables distributed portal development.
   – OKC, Alliance Portal, HotPage, QuakeSim, NEESGrid, CHEF,
     GridLab, many others have adopted approach.
                 What Is a Portlet?
• A portlet is a piece of Java code that runs in a Web server
  inside a container servlet.
• Portlets can do two things:
   – Perform non-visual operations such as make connections to remote
     hosts, perform operations.
       • Example: get a list of local files.
   – Create their display
• The portlet passes its display to its parent, which is
  responsible for constructing the entire display.
   – Typically this is HTML, with tables uses to organize component
   – Other displays are possible (VoiceXML, WML).
            Portlet Development
• Portlets may be either abstract types or instances.
   – Abstract types allow extensibility
• In support of this project, we have developed
  abstract portlets that can
   –   Maintain session state and manage multiple cookies.
   –   Make secure connections
   –   Pass form parameters
   –   Retain navigation of legacy JSP pages.

                                                  Turbine Servlet
                                                    VM template
                                                           ECS Root to HTML

 PSML                                             Screen Manager

                   PortletController                                    PortletController

                                 ECS                                      ECS        ECS


                           ECS              ECS                   ECS               ECS          ECS

 Portlets        Portlet                Portlet               Portlet           Portlet      Portlet

             RSS                       HTML                  JSP                WebPage     Local
               Portal Services
• We have several services that we are portletizing
  as part of this project:
   – Job submission
   – File Transfer
   – Job Monitoring
• We are developing DOD versions of TACC’s
  GPIR services
• We are extending Jetspeed login to support web
  kiniting (with SecurID).
              Job Submission
• Primarily based at ARL
  – Support Fluent, ANSYS, ABAQUS
  – Services construct GRD scripts, allow users to run and
    archive jobs.
• We are extending this to support ANSYS at ASC,
  DMEFS codes at ARL.
• We need to extend script generators for other
  queuing systems.
  – PBS, LoadLeveler, LSF
             File Management
• File management services allow you to
   – Upload, download files between desktop and remote
   – Download entire directories as zipped files.
   – Delete remote files.
   – Navigate remote directories.
   – Unzip/untar remotely.
• Targetting ASC and ARL initially
   – ARL is available in production
               Job Monitoring
• We have web interfaces that will allow to monitor
  your jobs on various hosts.
   – Constructs an HTML table of your running jobs in a
     unified format.
   – Allows you to stop jobs
• We support GRD in production portal at ARL.
• Have ported this to PBS, LSF, and LoadLeveler as
  part of this project.
             Access to Portlets
• Obviously not all users have accounts at all
   – An ASC file browser should be accessible only to users
     with an ASC account.
• Jetspeed has role based accessed control to
• Each user can be assigned to one or more user
  roles (“ERDC”, “ASC”, etc).
• This controls which portlets a user can add to his
  or her display.
  GridPort Information Repository
• Developed by TACC group for NPACI
• Porting this to DOD.
• Aim is to aggregate and cache grid and
  portal related data from multiple sources in
  a uniform way.
  – MDS, NWS, custom data providers
                    GPIR Approach
• GPIR is implemented as a set of Java Web Services, one to handle the
  input of GPIR data (Ingester WS) and another to facilitate the querying
  of that data (Query WS)
• The Ingester WS accepts or "ingests" several types of XML documents
  and stores them in a relational database (currently MySQL, Postgres).
    – These documents are created by a variety of means, including Java
      Clients that exist on the resources themselves, http "web scraping" of
      machine-specific flat-file formats, and queries of additional information
      providers such and MDS, GMS (Grid Monitor Service), and NWS
      (Network Weather Service).
• Persistently stored data can then be queried via the Query Web Service
  which uses the same XML resources used by the Ingester, in addition
  to some Query specific documents that can return XML such as
  Machine Summary data.
           GPIR Schema Types
• Static: static data for a machine.
• Load: load data for a machine.
• Status: machine status (up, down, unavailable).
• Downtime: downtime data for a machine.
• Jobs: job data for a machine.
• MOTD: Message of the Day data for a machine.
• Nodes: Nodes data for a machine.
• Services: represents the status of grid software running on
  a system.
• NWS: This returns bandwidth and latency measurements
  of the type returned by NWS.
            More Information
•   Contact:
•   GPIR:
•   Gateway:
•   DMEFS:
 Secure Web services

Choonhan Youn, Marlon Pierce and
         Geoffrey Fox
 EECS, Syracuse University and
    Community Grids Lab, IU
        Security Requirements for Web Services
• Need mutual authentication                                     Web Browser
  between clients and User                       Security ?
  Interface server
   – Clients are browsers: understand
     SSL but not Kerberos.
                                                                 User Interface
        tunnel http requests through a                             Server
         secure CORBA connection.
        provide a browser interface that will                SOAP                SOAP
         create a Kerberos TGT on the
         server for the user.                                        Security ?
• Need secure SOAP messages
  between user interface server and
  the repository and the service                      Service        SOAP
• Examples of problems if you
  have no security?
   Security Problems with Web
• How can I support single sign on?
• How do I authenticate the sender of the SOAP
• How do I control access to resources?
• How do I verify the message has arrived unaltered?
• How do I keep the contents of the message secret?
• How can I do this in a transparent way with a
  number of different mechanisms (Kerberos, PKI,
• How do I find out all the above attributes for a
  particular SOAP message?
    Integration of Security into Web Services
•   Authentication through single sign-on.                     Users
     – Kerberos, PKI
     – Distributed ticket system                            Authenticate
     – Getting assertions about authentication,                                  Security
       authorization, user attribute                                            Mechanism
•   SOAP security should be provided                             Generating
    through standard interfaces to specific                      Assertions
    mechanisms.                                                                    Signing
•   General methods are
     – Message signing.                                          Assertions
     – Message integrity.                                                          Encryption
     – Message encryption.
•   Kerberos, PKI are specific mechanisms.
•   Assertion is an XML document
    describing the information about                             Assertions
    authentication acts performed by
    subjects, attributes of subjects and                           SOAP
    authorization decisions, Created with a
    specific mechanism.                             HTTP      HTTP         ……      HTTP

                                                                              ……       Web
           Security Assertions
• SAML is a standard
                          SOAP Envelop
  security assertion
                           SOAP Header
  markup language.
                          SAML Assertion
• SAML assertions can
  be added to SOAP         SOAP Body
                          SOAP Message
• Assertions contain
  – Authentication info
  – Attributes
  – Authorization
          The client-side process
• Convert SAML schema to Java classes
   – Castor can be used to easily convert between XML and
      Java data objects.
• Develop utility classes for creating assertions, marshalling
  them back and forth between Java and SAML.
   – Assertion attributes filled in by the appropriate
• Login process: the authentication and getting the Kerberos
• Establish the security context with the server for getting
  the shared key.
• Generate user’s SAML security assertion.
• Sign the user assertion and SOAP Body messages.
• Rebuild the SOAP messages.
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv=""
 <soapenv:Header>                                                  The message structure of the
  <ns1:Saml xmlns:ns1="">
                                                                 SOAP request on the client-side.
  <ns2:SignedBody xmlns:ns2="">
<?xml version="1.0" encoding="UTF-8"?>
<ns1:AssertionSpecifier xmlns:ns1="">
  <ns1:Assertion MajorVersion="1" MinorVersion="0" AssertionID=""
     Issuer="Gateway Web Portal" IssueInstant="2003-05-30T14:54:28.957-05:00">
     <ns1:Conditions NotBefore="2003-05-30T14:49:28.957-05:00" NotOnOrAfter="2003-05-30T15:04:28.957-05:00">
        AuthenticationMethod="urn:ietf:rfc:1510" AuthenticationInstant="2003-05-30T14:54:28.957-05:00">
             SecurityDomain="" Name="gateway"/>
          <ns1:SubjectConfirmation>                                                                  SAML example
             <ns1:SubjectConfirmationData>A Kerberos Ticket</ns1:SubjectConfirmationData>
      <ns1:AuthenticationLocality IPAddress="" DNSAddress=""/>
     <ns1:AuthorizationDecisionStatement Resource="AccessLevel" Decision="Permit">
             SecurityDomain="" Name="gateway"/>
             <ns1:SubjectConfirmationData>A Kerberos Ticket</ns1:SubjectConfirmationData>
            The server-side process
• Establish the security context with client for getting the shared key.
• Handle the SOAP message.
    –   Secure assertion message.
    –   Secure body message.
    –   Security mechanism name such as Kerberos, PKI.
    –   Message format such as SAML, WS-security.
• Unwrap the secure assertion
• It checks the validity of the assertions.
    –   Issuer name
    –   “Conditions” time limit
    –   Subject name
    –   Authorization for accessing resources
• Unwrap SOAP body message
• Rebuild the SOAP message.
An assertion-based authentication                  The authentication
service for Gateway Web Services

           Client login process                    Process the SOAP
               for the user                            message

                                               Check    the   assertion
           Initialize the secure               type such as SAML,
            context to get the                 WS-security and the
                shared key.                    security     mechanism
                                               such as Kerberos, PKI.

              Generate the
            assertion such as
           SAML, WS-security.                    Unwrap the assertion.

                                               Test the user validity.
            Sign the assertion.

                                               Unwrap the SOAP Body
             Add it to SOAP                    message.

                                                   Rebuild the SOAP
           Sign the SOAP Body       Internet          message.
                 message.           (HTTP)
                                                   Process the SOAP
           Add it to SOAP Body.

             Send the SOAP
                request.                       Send the SOAP response.
      Multiple accesses in a distributed
    Usually, User Interface Server in computing portals federates a
  bunch of Web service proxies for accessing distributed services.
• When we use the client-server interaction fashion shown in the
  previous picture, the client has each secure session object on
  each distributed service.
• we need more effective system for handling client’s secure
  session object.
    – separating a secure server session object from an SOAP server which is
      running a bunch of Web services.
    – It is possible to use the messaging or event system, so called the Narada
      event brokering system developed by Community-Grids Lab. at Indiana
    – NaradaBrokering provides JMS compliance which follows the well-
      known publish-subscribe model.
    – Using NaradaBrokering system which is a messaging middleware, clients
      can interact with distributed computing services securely.
Interactions of secure Web service in
    a distributed environment - 1
 Web Browser                               Security
                                            (4)       (5)
   User Interface
                                         NaradaBrokering Server


   SOAP server             SOAP server            SOAP server
      A                       B                      C
     Interactions of secure Web service in a
           distributed environment - 2
1)   UIS establishes the security context with the “Security Handler” subscriber for
     getting the shared key.
2)   UIS makes secure SOAP message and then invoke the desired one of distributed
3)   The selected SOAP server (SOAP server A) extracts SOAP Header message and
     SOAP Body message, respectively from the secure SOAP message and then
     publishes them into the NaradaBrokering server.
4)   Those messages are processed in “Security Handler” subscriber which establishes
     and maintains a security context with the client for getting the shared session key
     that will be used for unwrapping the secure messages. It also checks the validity
     of the user assertion.
5)   “Security Handler” subscriber publishes the SOAP message with the decrypted
     SOAP Body message which is rebuilt in into the NaradaBrokering server if the
     test results for this user are valid.
6)   The selected SOAP server takes the SOAP message through the NaradaBrokering
     server and then makes a process it.
7)   UIS get the SOAP response message as the user’s service request.
8)   UIS try to interact with another distributed service without authenticating again
     (Step 1), following with the above procedures.
         Technical resources
• Modified Apache Axis 1.0: SOAP Engine
• Security assertion
  – SAML being standardized at OASIS is an
    XML-based security standard for exchanging
    authentication and authorization information.
  – SAML schema: draft-sstc-schema-assertion-
• Kerberos: Version 5, Release 1.2.2

To top