Colleagues
Since there are only three Mondays left
before RSA’10, I suggest we use the regular XSPA TC call this week to
make progress on the design, deployment, and testing of the RSA demonstration. This worked well during the preparations
for HIMSS, since many participants already had the time reserved. The next meeting is:
Friday, 05 February 2010, 01:00pm to
02:00pm ET
Dial in info: +1 800 767 1750
Access
code 97728 [i.e. XSPA T(C)]
Let’s add to the Friday agenda:
Status on the testbed
& availability of the development environment,
Brief presentation on the proposed
architecture,
Brief presentation on the use cases, and
Continued collaboration
on the demonstration.
After the initial presentations we can
turn over the rest of the meeting to your work (i.e. the continued
collaboration bullet). Duane, can
you get consensus on the presentations by Friday and submit a few slides prior
to the meeting? I realize these
would be provisional and subject to change. It looks like a lot for progress has been
made already.
Regards,
David
David Staggs, JD, CISSP
(SAIC)
Veterans Health Administration
Chief Health Informatics Office
Standards and Interoperability
Office: 858 433 1473
From: Duane DeCouteau [mailto:ddecouteau@sbcglobal.net]
Sent: Tuesday, February 02, 2010
2:07 AM
To: Sridhar Muppidi
Cc: Emory Fry; Hilal Fateh; Jerry
Goodnough; Davis, John M.; xspa-interop-tech; Tatyana Yatsunov
Subject: Re: [xspa-interop-tech]
Re: XSPA Testbed Operational
Nice work Sridhar, I believe Option #1 may make the
most sense and will extend vendor participation by allowing ACS (PEP,PIP,PDP)
to remain intact from the HIMSS 2009 Interop.
Below I have some questions and comments. Jiandong, Daniel can you
provide additional feedback as well.
Duane
1.) The WS-Client is a full Healthcare Domain with 1800+ patients loaded, web
services for clinical domains, and own Authorization Framework. The
Interop must demonstrate cross-enterprise healthcare exchange...
2.) STS: Trust Chain 1 -- The following are XSPA attributes that we could
obtain from the LDAP
urn:oasis:names:tc:xacml:1.0:subject:subject-id = Doctor,Bob
urn:oasis:names:tc:xspa:1.0:subject:npi = 999999 //CMS provided id to
uniquely identify provider
urn:oasis:names:tc:xpsa:1.0:subject:organization = Kaiser Permanente
urn:oasis:names:tc:xpsa:1.0:subject:organization-id --- 2.16.840.1.113883.3.364
urn:oasis:name:tc:xspa:1.0:subject:hl7:permission --- PRD-001, PRD-003, PRD-006
and so on
urn:oasis:names:tc:xacml:2.0:subject:role --- MD/Allopath //ASTM
Structured Role
3.) Application Level Attribute Knowledge --- In your diagrams I don't see
where these are asserted.
urn:oasis:names:tc:xspa:1.0:subject:functional-role --- physician //providers
role may change based on workflow
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse --- Treatment //
application may allow provider to override purpose of use based on patient need
urn:oasis:names:tc:xacml:1.0:resource:resource-id
--- Uniquely identifies patient across multiple healthcare domains...
urn:oasis:names:tc:xspa:1.0:resource:hl7:type
--- patient-search / medical-record / genotype / radiology / medications etc...
//clinical domain
urn:oasis:names:xacml:1.0:action:action-id --- create / read / update / delete
/ edit
urn:oasis:names:tc:xspa:1.0:environment:locality ---
4.) I assume that the WS-Client is vendor provided java libraries, or services,
and configuration files?
5.) Axis 2 Interceptor, when I see Axis I don't think standards based can you
elaborate. Also, this will replace the existing Interops
SAMLCallBackHandler?
6.) The client, ws-client, sts, ldap, axis interceptor will be located on
single VMSlice XSPADomainA
STS: Trust Chain 2
1.) The service provider is also a full healthcare domain with 1800+ plus
patient loaded. In this case the number of services are limited to those
that support the cross-enterprise healthcare exchange.
1.) The service provider, Axis 2 interceptor, STS, and Access Control System
(PEP,PIP,PDP), Attribute Services for organizational, and patient consent
policies, and OpenSSO which provides circle of trust to PDP from XACMLRequestProcessor
will be located on a single VMSlice XSPADomainB
2.) The Axis 2 Interceptor replaces the current SAMLValidator functionality.
3.) How does the STS interact with access control decision...is token issues if
ACS returns a deny?
Sridhar Muppidi wrote:
Duane and team,
Per our discussion on the call today, Craig and I captured the architecture
options for the interop in the following presentation.
(See attached file: Proposed Arch. for
Interop-draft1.ppt)
We can discuss the options and other open items either via email or wait till
our next call.
Thank you
Regards,
-Sridhar
__________________________________________________________________________________
Sridhar Muppidi, Ph.D | STSM, Sr. Security Architect, IBM Software Group | Phone:
+1 512.286.7689
Duane DeCouteau ---02/01/2010
07:17:20 PM---Testbed is back online...I restored the xspa schema on service
provider. There may be a bug in adm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Testbed is back
online...I restored the xspa schema on service provider. There may be a bug in
admin GUI on Domain B that created problem. I will look into this later
tonight.
Duane
Duane DeCouteau wrote:
All,
The XSPA Domains A & B (SAML and XACML Interops) are available on the ASU
site. My apologies for taking so long as firewall policies at the University
required me to update most of these from the command line. There are some minor
updates remaining which I may defer given our intent to migrate architecture to
WS-Trust.
Regards,
Duane
XSPA Domain A - Service Requestor
http://208.75.163.70/XACMLPatientPrivacy
Data Masking Use Case
User: drbob
Pass: xspa
PDP: Sun Microsystems
Patient: SASHA ARNOLD PatientId: 545482
Emergency Access/Fine Grain Access Control
User: nursealice (I still need to add the user to OpenSSO)
Pass: xspa
PDP: Sun Microsystems
Patient: SASHA ARNOLD PatientId: 545482
DoD Wounded Warrior
http://208.75.163.70/DoDDomainAClient/faces/CrossDomainLookup.jsp?patientName=NHINPATIENT,JOSEPH
XSPA Domain B - Service Provider (Organization and Patient Privacy Policy
Administration)
http://208.75.163.71/XSPASecurityServices
---------------------------------------------------------------------To unsubscribe from this mail list, you must leave the OASIS TC thatgenerates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php