xspa-interop-tech — archive

[Jiandong Guo <4b67dd35.8030805@sbcglobal.net>]

  
  


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


      

        

          

      From:
          

      Duane DeCouteau <ddecouteau@sbcglobal.net>
        
        

          

      To:
          

      xspa-interop-tech <xspa-interop-tech@lists.oasis-open.org>
        
        

          

      Cc:
          

      Emory Fry <eafry@gmx.com>,
"Davis, John
M." <Mike.Davis@va.gov>, Jerry
Goodnough <ferret@stormwoods.com>,
Hilal Fateh <fateh@soadex.com>,
Tatyana Yatsunov <yatsunov@gmail.com>
        
        

          

      Date:
          

      02/01/2010 07:17 PM
        
        

          

      Subject:
          

      [xspa-interop-tech] Re: XSPA Testbed
Operational
        
      
    
    

    



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