Docstoc

Interoperable Portal Services.ppt - Indiana University

Document Sample
Interoperable Portal Services.ppt - Indiana University Powered By Docstoc
					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
      connection.
    – Web server typically located in
      “DMZ”                             krcp, krsh
• Web server manages session
  IDs, invokes backend requests
  with Kerberos client utilities.                HPC            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
     displays.
   – 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.
                                                       HTML


                                                  Turbine Servlet
                                                    VM template
                                                           ECS Root to HTML

 PSML                                             Screen Manager
                                                                  ECS

                   PortletController                                    PortletController

                                 ECS                                      ECS        ECS

PortletControl




                           ECS              ECS                   ECS
                                                                                    ECS          ECS



 Portlets        Portlet                Portlet               Portlet           Portlet      Portlet


             RSS                       HTML                 JSP                 WebPage     Local
 Data
               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
     HPC
   – 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
  centers.
   – An ASC file browser should be accessible only to users
     with an ASC account.
• Jetspeed has role based accessed control to
  portlets.
• 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
              (GPIR)
• Developed by TACC group for NPACI
  resources.
• 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: marpierc@indiana.edu
•   GPIR: http://www.tacc.utexas.edu/grid/gpir/
•   Gateway: http://www.gatewayportal.org.
•   DMEFS:
    http://www.erc.msstate.edu/~haupt/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
                                                                                     Service
                                                                                    Repository
                                                     Provider
  provider.
• Examples of problems if you
  have no security?
   Security Problems with Web
             Services
• How can I support single sign on?
• How do I authenticate the sender of the SOAP
  message?
• 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,
  GSI)?
• 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
                                                  Service
                                                                  Web
                                                                 Service
                                                                              ……       Web
                                                                                      Service
           Security Assertions
                             HTTP
• SAML is a standard
                          SOAP Envelop
  security assertion
                           SOAP Header
  markup language.
                          SAML Assertion
• SAML assertions can
  be added to SOAP         SOAP Body
  messages.
                          SOAP Message
• Assertions contain
  – Authentication info
  – Attributes
  – Authorization
    Decisions
          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
      mechanism.
• Login process: the authentication and getting the Kerberos
  ticket.
• 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="http://schemas.xmlsoap.org/soap/envelope/"
           xmlns:xsd="http://www.w3.org/2001/XMLSchema"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Header>                                                  The message structure of the
  <ns1:Saml xmlns:ns1="http://www.gatewayportal.org/sign.xsd">
                                                                 SOAP request on the client-side.
   <ns1:SignedAssertion>
        YIIIYwYJKoZIhvcSAQICAgEAAAAA//9a+0MDxeg14f8T5vf0o7jm9z4ml2Fj
         azlhwxyd/kZz8pgWbREMMZF2ELm9G+MFojzGKt0F6B91gBuJ1QL+QN5kM
                      ……………………………………………………………..
                      ……………………………………………………………..
         n8cdEhjskpcEYP2MvnRwxJmei9U5m3IToiHDI3foZ2TjhwPn
   </ns1:SignedAssertion>
   <ns1:SecurityMechanism>Kerberos</ns1:SecurityMechanism>
   <ns1:UserName>gateway@CG.INDIANA.EDU</ns1:UserName>
  </ns1:Saml>
 </soapenv:Header>
 <soapenv:Body>
  <ns2:SignedBody xmlns:ns2="http://www.gatewayportal.org/signbody.xsd">
       YIIBawYJKoZIhvcSAQICAgEAAAAA//9NPq5TRhFcyfMdAYFS1XHlBzI3JhN+c15
       z0MncshbXb9zQ3Z8b6QkJHCmWZuVBXvyVSaDZ4GVgbwnicAJSGEj6OJVTxqQfH
                  ………………………………………………………………
                  ………………………………………………………………
       YFKg/LQJ0oleULSsP2k9HQY+MxD64IYaw9lSVOX9IHtc+uZyQ==
  </ns2:SignedBody>
 </soapenv:Body>
</soapenv:Envelope>
<?xml version="1.0" encoding="UTF-8"?>
<ns1:AssertionSpecifier xmlns:ns1="http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-27.xsd">
  <ns1:Assertion MajorVersion="1" MinorVersion="0" AssertionID="156.56.104.10.1054324468957"
     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">
        <ns1:AudienceRestrictionCondition>
           <ns1:Audience>http://www.gatewayportal.org/agreement.xml</ns1:Audience>
        </ns1:AudienceRestrictionCondition>
     </ns1:Conditions>
     <ns1:AuthenticationStatement
        AuthenticationMethod="urn:ietf:rfc:1510" AuthenticationInstant="2003-05-30T14:54:28.957-05:00">
       <ns1:Subject>
           <ns1:NameIdentifier
             SecurityDomain="www.gatewayportal.org" Name="gateway"/>
           <ns1:SubjectConfirmation>                                                                 SAML example
             <ns1:ConfirmationMethod>urn:ietf:rfc:1510</ns1:ConfirmationMethod>
             <ns1:SubjectConfirmationData>A Kerberos Ticket</ns1:SubjectConfirmationData>
           </ns1:SubjectConfirmation>
       </ns1:Subject>
      <ns1:AuthenticationLocality IPAddress="156.56.104.10" DNSAddress="grids.ucs.indiana.edu"/>
     </ns1:AuthenticationStatement>
     <ns1:AuthorizationDecisionStatement Resource="AccessLevel" Decision="Permit">
        <ns1:Subject>
           <ns1:NameIdentifier
             SecurityDomain="www.gatewayportal.org" Name="gateway"/>
           <ns1:SubjectConfirmation>
             <ns1:ConfirmationMethod>urn:ietf:rfc:1510</ns1:ConfirmationMethod>
             <ns1:SubjectConfirmationData>A Kerberos Ticket</ns1:SubjectConfirmationData>
           </ns1:SubjectConfirmation>
        </ns1:Subject>
        <ns1:Actions>
           <ns1:Action>5</ns1:Action>
        </ns1:Actions>
     </ns1:AuthorizationDecisionStatement>
  </ns1:Assertion>
</ns1:AssertionSpecifier>
            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
service for Gateway Web Services

           Client login process                    Process the SOAP
                for the user                           message
               authenticatio n



                                               Check    the   assertio n
           Initialize the secure               type such as SAML,
             context to get the                WS-security and the
                                    Client
                 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.


                                               Unw rap the SO AP Body
              Add it to SOAP                   message.
                 Header.


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


              Send the SOAP
                 request.                      Send the SOAP response.
      Multiple accesses in a distributed
•
                             system
    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
      University.
    – 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
                                           Handler
                          (1)
                                            (4)       (5)
   User Interface
      Server
                                         NaradaBrokering Server

                    (8)
  (2)
        (7)
                          (6)
              (3)


   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
     services.
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-
    27.xsd
• Kerberos: Version 5, Release 1.2.2

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:4/4/2012
language:
pages:38