My apologies Jiandong this email was stuck in my spam folder. Thank
you for your input here and at today's meeting.
Duane
Jiandong Guo wrote:
4B69312E.6080306@sun.com" type="cite">
Option 1 is more or less the different model to do more or less same
thing as the one proposed in the original XSPA WS-Trust profile.
The difference is that the original one require that one can only
access the service Provider with the token
from the STS in the service domain. It is fine for me with both the
models.
1. Trust chain, Axis 2 interceptor etc, are implementation specific. We
should still use domain STS ...
2. We need more specific about what the service domain STS to do:
* authentication/validation
* authorization/access control; interact with ACS? (not show in
the picture)
* what to issue? with Validation protocol, you can have status, a
different token (with the same attributes as the one in the SAML
assertion being validated or mapping to local identity and attributes)
3. We still need to agree upon if we want to have the run time
attributes in the SAML assertion. If yes, we wan to use the custom
Direct for the Claims for it.
Thanks!
Jiandong
Duane DeCouteau wrote:
4B67DD35.8030805@sbcglobal.net" type="cite">
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 --- Kaiser Foundation
Hospital //clinic location etc.
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:
OF95B57B0F.A2C36E6C-ON862576BE.001BD9C1-862576BE.001C46E5@us.ibm.com" type="cite">
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 that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php