Interoperable Portal Services
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
740
On Slideshare
740
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Interoperable Portal Services Marlon Pierce Community Grids Lab Indiana University
  • 2. 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
  • 3. Portal Security
    • We are building off Gateway’s approach for Web-based security for DOD portals.
      • Approved for ARL and ASC
    • Users kinit to a web server to get a ticket.
      • SSL, MD’d sessions, Certificates maintain secure connection.
      • Web server typically located in “DMZ”
    • Web server manages session IDs, invokes backend requests with Kerberos client utilities.
    Browser Web Server HPC HPC HPC DMZ HTTPS krcp, krsh
  • 4. 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.
  • 5. 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).
  • 6. 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.
  • 7. Portlet Portlet Portlet Portlet RSS HTML JSP WebPage Portlet Local Portlets Data PortletController PortletController Screen Manager HTML PSML PortletControl ECS VM template ECS ECS ECS ECS ECS ECS ECS ECS Root to HTML ECS Turbine Servlet
  • 8.  
  • 9.  
  • 10.  
  • 11. 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).
  • 12. 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
  • 13.  
  • 14.  
  • 15.  
  • 16. 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
  • 17.  
  • 18. 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.
  • 19. 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.
  • 20. 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
  • 21. 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.
  • 22.  
  • 23. 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.
  • 24. More Information
    • Contact: [email_address]
    • GPIR: http://www.tacc.utexas.edu/grid/gpir/
    • Gateway: http://www.gatewayportal.org .
    • DMEFS: http://www.erc.msstate.edu/~haupt/DMEFS/
  • 25. Secure Web services Choonhan Youn, Marlon Pierce and Geoffrey Fox EECS, Syracuse University and Community Grids Lab, IU
  • 26. Security Requirements for Web Services
    • Need mutual authentication between clients and User Interface server
      • Clients are browsers: understand SSL but not Kerberos.
        • tunnel http requests through a secure CORBA connection.
        • provide a browser interface that will create a Kerberos TGT on the server for the user.
    • Need secure SOAP messages between user interface server and the repository and the service provider.
    • Examples of problems if you have no security?
    Web Browser User Interface Server Security ? SOAP SOAP SOAP Service Repository Service Provider Security ?
  • 27. 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?
  • 28. Integration of Security into Web Services
    • Authentication through single sign-on.
      • Kerberos, PKI
      • Distributed ticket system
      • Getting assertions about authentication, authorization, user attribute
    • SOAP security should be provided through standard interfaces to specific mechanisms.
    • General methods are
      • Message signing.
      • Message integrity.
      • Message encryption.
    • Kerberos, PKI are specific mechanisms.
    • Assertion is an XML document describing the information about authentication acts performed by subjects, attributes of subjects and authorization decisions, Created with a specific mechanism.
    Users Security Mechanism Web Service Web Service Web Service …… Assertions Signing Encryption Authenticate Generating Assertions …… HTTP HTTP HTTP Assertions SOAP
  • 29. Security Assertions
    • SAML is a standard security assertion markup language.
    • SAML assertions can be added to SOAP messages.
    • Assertions contain
      • Authentication info
      • Attributes
      • Authorization Decisions
    HTTP SOAP Envelop SOAP Body SOAP Message SOAP Header SAML Assertion
  • 30. 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.
  • 31. <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <soapenv:Envelope xmlns:soapenv=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot;> <soapenv:Header> <ns1:Saml xmlns:ns1=&quot;http://www.gatewayportal.org/sign.xsd&quot;> <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=&quot;http://www.gatewayportal.org/signbody.xsd&quot;> YIIBawYJKoZIhvcSAQICAgEAAAAA//9NPq5TRhFcyfMdAYFS1XHlBzI3JhN+c15 z0MncshbXb9zQ3Z8b6QkJHCmWZuVBXvyVSaDZ4GVgbwnicAJSGEj6OJVTxqQfH ……………………………………………………………… ……………………………………………………………… YFKg/LQJ0oleULSsP2k9HQY+MxD64IYaw9lSVOX9IHtc+uZyQ== </ns2:SignedBody> </soapenv:Body> </soapenv:Envelope> The message structure of the SOAP request on the client-side.
  • 32.
    • <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
    • <ns1:AssertionSpecifier xmlns:ns1=&quot;http://www.oasis-open.org/committees/security/docs/draft-sstc-schema-assertion-27.xsd&quot;>
    • <ns1:Assertion MajorVersion=&quot;1&quot; MinorVersion=&quot;0&quot; AssertionID=&quot;156.56.104.10.1054324468957&quot;
    • Issuer=&quot;Gateway Web Portal&quot; IssueInstant=&quot;2003-05-30T14:54:28.957-05:00&quot;>
    • <ns1:Conditions NotBefore=&quot;2003-05-30T14:49:28.957-05:00&quot; NotOnOrAfter=&quot;2003-05-30T15:04:28.957-05:00&quot;>
    • <ns1:AudienceRestrictionCondition>
    • <ns1:Audience>http://www.gatewayportal.org/agreement.xml</ns1:Audience>
    • </ns1:AudienceRestrictionCondition>
    • </ns1:Conditions>
    • <ns1:AuthenticationStatement
    • AuthenticationMethod=&quot;urn:ietf:rfc:1510&quot; AuthenticationInstant=&quot;2003-05-30T14:54:28.957-05:00&quot;>
    • <ns1:Subject>
    • <ns1:NameIdentifier
    • SecurityDomain=&quot;www.gatewayportal.org&quot; Name=&quot;gateway&quot;/>
    • <ns1:SubjectConfirmation>
    • <ns1:ConfirmationMethod>urn:ietf:rfc:1510</ns1:ConfirmationMethod>
    • <ns1:SubjectConfirmationData>A Kerberos Ticket</ns1:SubjectConfirmationData>
    • </ns1:SubjectConfirmation>
    • </ns1:Subject>
    • <ns1:AuthenticationLocality IPAddress=&quot;156.56.104.10&quot; DNSAddress=&quot;grids.ucs.indiana.edu&quot;/>
    • </ns1:AuthenticationStatement>
    • <ns1:AuthorizationDecisionStatement Resource=&quot;AccessLevel&quot; Decision=&quot;Permit&quot;>
    • <ns1:Subject>
    • <ns1:NameIdentifier
    • SecurityDomain=&quot;www.gatewayportal.org&quot; Name=&quot;gateway&quot;/>
    • <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>
    SAML example
  • 33. 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.
  • 34. An assertion-based authentication service for Gateway Web Services Client login process for the user authentication Initialize the secure context to get the shared key. Generate the assertion such as SAML, WS-security. Sign the assertion. Add it to SOAP Header. Sign the SOAP Body message. Add it to SOAP Body. Send the SOAP request. The authentication service Process the SOAP message Check the assertion type such as SAML, WS-security and the security mechanism such as Kerberos, PKI. Unwrap the assertion. Test the user validity. Unwrap the SOAP Body message. Rebuild the SOAP message. Process the SOAP message. Send the SOAP response. Internet (HTTP) cloud Client
  • 35. 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.
  • 36. Interactions of secure Web service in a distributed environment - 1 (2) (8) (4) (5) (6) (3) (7) (1) NaradaBrokering Server User Interface Server Web Browser SOAP server A SOAP server C Security Handler SOAP server B
  • 37. Interactions of secure Web service in a distributed environment - 2
    • UIS establishes the security context with the “Security Handler” subscriber for getting the shared key.
    • UIS makes secure SOAP message and then invoke the desired one of distributed services.
    • 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.
    • 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.
    • “ 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.
    • The selected SOAP server takes the SOAP message through the NaradaBrokering server and then makes a process it.
    • UIS get the SOAP response message as the user’s service request.
    • UIS try to interact with another distributed service without authenticating again (Step 1), following with the above procedures.
  • 38. 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