Transcript 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.

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
approach for Web-based
security for DOD portals.
Browser
HTTPS
– 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.
DMZ
Web
Server
krcp, krsh
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
Screen Manager
PSML
ECS
PortletController
PortletController
ECS
ECS
ECS
PortletControl
ECS
Portlets
Data
Portlet
RSS
ECS
Portlet
HTML
ECS
Portlet
JSP
ECS
Portlet
WebPage
ECS
Portlet
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
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: [email protected]
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
between clients and User
Interface server
Web Browser
Security ?
– 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?
User Interface
Server
SOAP
SOAP
Security ?
Service
Provider
SOAP
Service
Repository
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
– Getting assertions about authentication,
authorization, user attribute
•
•
Authenticate
Generating
Assertions
SOAP security should be provided
through standard interfaces to specific
mechanisms.
General methods are
Signing
Assertions
– 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.
Security
Mechanism
Encryption
Assertions
SOAP
HTTP
Web
Service
HTTP
Web
Service
……
……
HTTP
Web
Service
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 Header
SAML Assertion
SOAP Body
SOAP Message
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>[email protected]</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>
<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>
SAML example
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
service for Gateway Web Services
The authentication
service
Process the SOAP
message
Client login process
for the user
authentication
Initialize the secure
context to get the
shared key.
Client
Generate the
assertion such as
SAML, WS-security.
Unwrap the assertion.
Test the user validity.
Sign the assertion.
Unwrap the SOAP Body
message.
Add it to SOAP
Header.
Sign the SOAP Body
message.
Check
the
assertion
type such as SAML,
WS-security and the
security
mechanism
such as Kerberos, PKI.
Internet
(HTTP)
cloud
Rebuild the SOAP
message.
Add it to SOAP Body.
Process the SOAP
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 wellknown 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)
User Interface
Server
(5)
NaradaBrokering Server
(2)
(8)
(7)
(6)
(3)
SOAP server
A
SOAP server
B
SOAP server
C
Interactions of secure Web service in a
distributed environment - 2
1)
2)
3)
4)
5)
6)
7)
8)
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.
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-assertion27.xsd
• Kerberos: Version 5, Release 1.2.2