I was fortunate to utilize PicketLink (http://jboss.org/picketlink) in a Technology Demonstration (interoperability exercise) at HIMSS 2009, April 2009 at Chicago. The other participants were Sun Microsystems, Jericho Systems, US Department of Veterans Affairs and the US Department of Defense. I have reported on this in the past. We used PicketLink mainly for the SAML and XACML capabilities. The associated Oasis press release is OASIS and HITSP Collaborate on Interoperability Demo of Healthcare Privacy Standards at HIMSS09.
While we are on the topic, I am extremely glad to read the latest news item from the Oasis Consortium related to the use of XACML and SAML standards in the US Healthcare infrastructure. The news is OASIS Members Approve Security and Privacy Authorization Standards for Healthcare.
As co-chair of the Oasis XSPA Technical Committee that was the driver of the two profiles (one on SAML and one on XACML) that became Oasis standards recently, I was able to contribute and support these two profiles. I am pleased that Oasis XACML and Oasis SAML standards have made headway into being mandated for use in the US Federal Agencies. Hopefully, these two standards should play a pivotal role in the widespread usage of the National Health Information Network (NHIN), whose open source based initiative is CONNECT.
Showing posts with label xspa. Show all posts
Showing posts with label xspa. Show all posts
Wednesday, December 23, 2009
Monday, December 15, 2008
Federated Identity Support with JBoss
People ask me the following questions:
* when are we getting SAML support in JBoss?
* when will we get a formal identity management solution for JBoss community and enterprise users?
For a while, I have been deferring answering this basically to first get a clear picture of the stabilization of the federated identity space. In addition, we had the great JBoss Application Server v5.0 to be sent out of the door with great security features.
Given this, what are our plans?
JBoss Identity:
Various projects under the JBoss umbrella have gotten together with stakeholders and formed this project called as "JBoss Identity". JBoss Application Server, JBoss Portal, JBoss SOA, JBoss Rules/Drools, JBoss Seam etc will all utilize the work from this common project.
Results Desired:
JBoss Identity Management (Management of Users, roles etc) for a single domain
JBoss Identity Federation (Allow support for federated identity standards)
Design: http://www.jboss.com/index.html?module=bb&op=viewforum&f=284
JIRA: https://jira.jboss.org/jira/browse/JBID
Going forward, we want to support the following standards from a federated identity perspective:
1) SAML v2.0
2) WS-Trust
3) Liberty ID-WSF
These 3 standards are important for the JBoss SOA Platform.
Roadmap:
JBoss Identity Federation v1.0.0 (February 28, 2009)
SAMLv2.0
SAML core Structures
Web Browser SSO Profile
- HTTP/Redirect Binding - Jan 15, 2009 (with Signature support)
- HTTP/Post Binding - Feb 15, 2009 (With Signature support)
WS-Trust (Parallel work with SAML)
JBoss Identity Federation v1.1.0 (May 31, 2009)
SAML v2.0
- Encryption Support to Web Browser SSO Profile
- Identity Provider Discovery Profile
Liberty ID-WSF
Note: These dates are subject to change.
Challenges: It takes years (if not close to a decade) to actually get a fully compliant federated identity management solution. There are a lot of issues involved - testing, complex configuration, complex diverse requirements etc. So, we will follow the path of least resistance - listen to our users as to what their needs are.
* We have to make the system very simple to configure (of course we should assume reasonable defaults). No point in piling on to the configuration headache associated with security.
* We will allow the system to work with the great container security (JBoss/Tomcat). Why reinvent the wheel?
How can you help?
Please use the following thread to talk to us with use cases etc and be early adopters of out technology.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196628
Events:
JBoss Identity will be put to test at the Oasis XSPA Interoperability event at HIMSS 2009 in April 2009 at Chicago. We will use SAML v2.0, XACML v2.0 and WS-Trust applied to use cases in the health care sector.
Vision: JBoss Identity along with Identity Federation, supplemented with JBoss XACML, will enable federated identity as well as federated authorization support for the community.
* when are we getting SAML support in JBoss?
* when will we get a formal identity management solution for JBoss community and enterprise users?
For a while, I have been deferring answering this basically to first get a clear picture of the stabilization of the federated identity space. In addition, we had the great JBoss Application Server v5.0 to be sent out of the door with great security features.
Given this, what are our plans?
JBoss Identity:
Various projects under the JBoss umbrella have gotten together with stakeholders and formed this project called as "JBoss Identity". JBoss Application Server, JBoss Portal, JBoss SOA, JBoss Rules/Drools, JBoss Seam etc will all utilize the work from this common project.
Results Desired:
JBoss Identity Management (Management of Users, roles etc) for a single domain
JBoss Identity Federation (Allow support for federated identity standards)
Design: http://www.jboss.com/index.html?module=bb&op=viewforum&f=284
JIRA: https://jira.jboss.org/jira/browse/JBID
Going forward, we want to support the following standards from a federated identity perspective:
1) SAML v2.0
2) WS-Trust
3) Liberty ID-WSF
These 3 standards are important for the JBoss SOA Platform.
Roadmap:
JBoss Identity Federation v1.0.0 (February 28, 2009)
SAMLv2.0
SAML core Structures
Web Browser SSO Profile
- HTTP/Redirect Binding - Jan 15, 2009 (with Signature support)
- HTTP/Post Binding - Feb 15, 2009 (With Signature support)
WS-Trust (Parallel work with SAML)
JBoss Identity Federation v1.1.0 (May 31, 2009)
SAML v2.0
- Encryption Support to Web Browser SSO Profile
- Identity Provider Discovery Profile
Liberty ID-WSF
Note: These dates are subject to change.
Challenges: It takes years (if not close to a decade) to actually get a fully compliant federated identity management solution. There are a lot of issues involved - testing, complex configuration, complex diverse requirements etc. So, we will follow the path of least resistance - listen to our users as to what their needs are.
* We have to make the system very simple to configure (of course we should assume reasonable defaults). No point in piling on to the configuration headache associated with security.
* We will allow the system to work with the great container security (JBoss/Tomcat). Why reinvent the wheel?
How can you help?
Please use the following thread to talk to us with use cases etc and be early adopters of out technology.
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4196628
Events:
JBoss Identity will be put to test at the Oasis XSPA Interoperability event at HIMSS 2009 in April 2009 at Chicago. We will use SAML v2.0, XACML v2.0 and WS-Trust applied to use cases in the health care sector.
Vision: JBoss Identity along with Identity Federation, supplemented with JBoss XACML, will enable federated identity as well as federated authorization support for the community.
Wednesday, June 25, 2008
Oasis Cross-Enterprise Security And Privacy Authorization (XSPA) Technical Committee
Mark and I have supported a proposed Oasis Technical Committee Charter.
http://lists.oasis-open.org/archives/tc-announce/200806/msg00007.html
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS CROSS-ENTERPRISE SECURITY AND PRIVACY AUTHORIZATION (XSPA) TECHNICAL
COMMITTEE
1a. Name
OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
1b. Statement of Purpose
Enterprises, including the healthcare enterprise, need a mechanism to exchange
privacy policies, consent directives and authorizations in an interoperable
manner. At this time, there is no standard that provides a cross-enterprise
security and privacy profile. The OASIS Cross-Enterprise Security and Privacy
Authorization (XSPA) TC will address this gap.
The need for an XSPA profile has been identified by the security and privacy
working group of the Healthcare Information Technology Standards Panel (HITSP).
HITSP is an ANSI-sponsored body charged with identifying standard building
blocks that can be leveraged to implement common healthcare use cases. The XSPA
profile will require the participation of subject matter experts in several
areas, including WS-Federation, SAML, WS-Trust, and possibly others noted below.
OASIS has the unique combination of member expertise necessary to complete this
work.
The purpose of the XSPA profile is to address common needs: allow parties to
adopt a set of methods that, taken together, will enable them immediately
interoperate with other diverse participants in the same data exchanges; use
readily available open standards, so that participation is broadly possible
without significant licensing limitations, hardware or software choice
constraints or single-source vendor risks; and provide a fully specified stack
or set of specifications or options, all known to be interoperable. The
foregoing needs are especially acute when the use of a particular set of methods
is mandated, either by law or as a practical matter by its adoption by central
actors in a mandatory system.
Governmental health regulators are increasingly requiring certain parties
exchange health and health payment information (such as personal health records,
and itemize statements of health care charges and benefit payments) in
electronic form, and use sets of data standards identified as broadly suitable
and secure. Similar government-sponsored or government-encouraged
standardization projects are underway in many other countries. The XSPA profile
will provide another "building block" in the creation of large scale
interoperability of health information. These profiles will also aid in
achieving interoperability for secure data exchange among various health care
entities including providers, hospitals, pharmacies and insurance companies. It
is envisioned that the work produced by this committee will also help the
National Health Information Network (NHIN) in the US for secure data exchange.
It specifying the XSPA profile, where stable open standards exist, they should
be noted and adopted. Where functions are not available, or some connective
choices or additional material is required, it will be created. Doing so is the
purpose for this committee's creation.
The profile specified by this TC will have broad applicability to health
communities beyond the regulated portion of U.S. healthcare data transactions
that the HITSP panel is directed to address. Use cases from other instances of
cognate data exchanges, particularly in healthcare privacy contexts, may be
solicited and used to improve the TC's work. However, the first priority of
this committee will be to deliver and demonstrate sets of standards-based
methods that fulfill the identified security & privacy functions needed by
HITSP's specifications of functions and mandates.
The XSPA TC may also cover a more general enterprise server profile which will
provide the building blocks for business models and industry applications. Some
of the models investigated will include enterprise security and more generally
SOA security. Application of how these security and privacy models apply to
different industry sectors, including domains such as finance where privacy
rights must be supported, will also be investigated if time permits.
1c. Scope
The purpose of the TC is to specify sets of stable open standards and profiles,
and create other standards or profiles as needed, to fulfill the security and
privacy functions identified by the functions and data practices identified by
HITSP, or specified in its use cases, as all are mandated or specified from time
to time. These functions will at a minimum support the HITSP Access Control
Transaction Package specification TP20, including those access control
capabilities required to support the HITSP Manage Consent Directive Package
specification TP30. This includes the support of reliable and auditable methods
to identify, select and confirm the personal identity, official authorization
status, and role data for the subjects, senders, receivers and intermediaries of
electronic data; data needed to convey and/or enforce permitted operations on
resources and associated conditions and obligations; and reasonable measures to
secure and maintain the privacy and integrity of that data from end to end.
1. The TC may identify existing, stable open standards, and sets of standards,
and alternative standards, extensions and profiles, for fulfilling each of the
HITSP-identified functions and use cases. Where HITSP subject-matter-specific
profiles have already identified such standards as recommended, those approved
standards will be included in the TC's identified sets of standards. Where the
TC identifies elements or alternatives not already so identified as recommended,
the TC should, if it believes the additional alternatives are necessary or
advisable, recommend their inclusion to the appropriate HITSP expert panel.
2. The TC may create and approve specifications, and extensions or profiles of
specifications, as needed to fulfill HITSP-identified functions and use cases
not satisfied by existing stable open standards. Contributions made to the
committee for work issued by the committee itself will be subject to the OASIS
IPR Policy. Any such work must include appropriate conformance clause or test
information. Such work will be recommended for inclusion, as appropriate, in
the standing recommendations of the appropriate HITSP expert panel.
3. The TC may elect, in the above specifications, extensions or profile, to
indicate methods for the fulfillment of other publicly-available health-related
use cases (or mandates), or functions described in those use cases (or
mandates), including from other regions and other regulatory regimes; and may
elect to create and approve additional specifications, and extensions or
profiles of specifications, as needed, to fulfill those use cases or component
functions.
4. The TC may elect to elaborate or extend any of the above use cases or
functions, publish the same and create additional standards, profiles or
extensions to support those augmented use cases or functional descriptions. In
any such augmented work the TC must specify whether it is intended to fulfill an
HITSP (or other) mandate. Any such work must include appropriate conformance
clause or test information. Such work completed may be recommended for
inclusion, as appropriate, in the recommendations or reports of any relevant
health regulatory or advisory body.
5. The TC may elect to create supplemental information regarding the above
matters such as demonstrations, implementation guides, best practices, FAQs, or
other explanatory, implementation or promotional material as it may deem useful.
6. In all of its work, the TC should, to the extent feasible, prefer widely
implementable, widely interoperable, modular standards, extensions, profiles and
methods that permit use by a variety of participants with diverse hardware,
software, data architecture and messaging practices. The TC intends to ask
OASIS to contribute all or part of its final work, as relevant, HITSP or related
panels for incorporation into its recommendations and mandates.
1d. List of Deliverables
1. A list of the specific HITSP use cases and functions that the TC plans to
fulfill, by October 2008.
2. A set of specifications, sets, profiles and extensions, as described in
paragraphs #1 and #2 under 'Scope', to fulfill each of the HITSP use cases and
functions identified for fulfillment in deliverable paragraph #1, with the first
such specification or profile to be approved as a Committee Specification by
[December 2008], and the remainder if any to be approved by Committee
Specifications by [June 2009]. The TC may elect to create one or more of such
deliverables in whatever combinations it deems appropriate.
3. An interoperability demonstration of the XSPA profile, consistent with
paragraph #5 under 'Scope,' demonstrating the end-to-end enforcement of
healthcare security policy at the HIMSS (Healthcare Information and Management
Systems Society) meeting (April 2009).
4. Optionally, such other deliverables (e.g., those listed in paragraphs 1-6
under 'Scope') as the TC may elect, until the later of December 2009 or such
later date as the TC may elect to conclude.
1e. IPR Mode:
Royalty Free on Limited Terms under the OASIS IPR Policy
1f. Anticipated Audiences:
Health-related data transaction participants, especially in exchanges subject to
security or privacy regulation; regulators of healthcare, health payment and
personal privacy; vendors and integrators supplying products or services to the
foregoing; and, secondarily, participants in regulated or closely monitored
data exchanges with privacy and security requirements in other topical fields.
1g. Language:
English
(2) Non-normative information regarding the startup of the TC, which includes:
(2)(a) Identification of similar or applicable work that is being done in other
OASIS TCs or by other organizations, why there is a need for another effort in
this area and how this proposed TC will be different, and what level of liaison
will be pursued with these other organizations.
The proposed Cross-Enterprise Security and Privacy Authorization (XSPA) TC will
be incorporating several standards in a profile allowing the exchange of privacy
policies, consent directives and authorizations in an interoperable manner. The
need for an XSPA profile has been identified by the security and privacy working
group of the ANSI-sponsored Healthcare Information Technology Standards Panel
(HITSP). No other organization is addressing this identified gap in standards.
The profile will use standards from several OASIS TCs: SAML (SSTC), WS-Trust
(WS-SX) and XACML. Liaison will be established by concurrent work items in the
cited TCs' area of expertise.
(2)(b) The date, time, and location of the first meeting, whether it will be
held in person or by telephone, and who will sponsor this first meeting. The
first meeting of a TC shall occur no less than 30 days after the announcement of
its formation in the case of a meeting held exclusively by telephone or other
electronic means, and no less than 45 days after the announcement of its
formation in the case of a meeting held face-to-face (whether or not a telephone
bridge is also available).
The proposed XSPA TC will hold the first official meeting on August 8, 2008 by
telephone and will use a free conference call service.
(2)(c) The projected on-going meeting schedule for the year following the
formation of the TC, or until the projected date of the final deliverable,
whichever comes first, and who will be expected to sponsor these meetings.
The TC will meet biweekly or as otherwise agreed upon by the members of the
technical committee.
(2)(d) The names, electronic mail addresses, and membership affiliations of at
least Minimum Membership who support this proposal and are committed to the
Charter and projected meeting schedule.
Mark Little (Redhat)
Anil Saldhana (Redhat)
Sampo Kellomki (Symlabs)
Anil Tappetla (Cisco)
David Staggs (Veterans Health Administration)
(2)(e) The name of the Convener who must be an Eligible Person.
David Staggs.
(2)(f) The name of the Member Section with which the TC intends to affiliate, if
any.
None.
(2)(g) Optionally, a list of contributions of existing technical work that the
proposers anticipate will be made to this TC.
None.
(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document regarding
the planned scope of the TC, for posting on the TC's website.
To be provided at a later date.
(2)(i) Optionally, a proposed working title and acronym for the specification(s)
to be developed by the TC.
To be provided at a later date.
=============================================================================
I strongly feel that this TC is a great step toward health care security.
http://lists.oasis-open.org/archives/tc-announce/200806/msg00007.html
===========
PROPOSED CHARTER FOR REVIEW AND COMMENT
OASIS CROSS-ENTERPRISE SECURITY AND PRIVACY AUTHORIZATION (XSPA) TECHNICAL
COMMITTEE
1a. Name
OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC
1b. Statement of Purpose
Enterprises, including the healthcare enterprise, need a mechanism to exchange
privacy policies, consent directives and authorizations in an interoperable
manner. At this time, there is no standard that provides a cross-enterprise
security and privacy profile. The OASIS Cross-Enterprise Security and Privacy
Authorization (XSPA) TC will address this gap.
The need for an XSPA profile has been identified by the security and privacy
working group of the Healthcare Information Technology Standards Panel (HITSP).
HITSP is an ANSI-sponsored body charged with identifying standard building
blocks that can be leveraged to implement common healthcare use cases. The XSPA
profile will require the participation of subject matter experts in several
areas, including WS-Federation, SAML, WS-Trust, and possibly others noted below.
OASIS has the unique combination of member expertise necessary to complete this
work.
The purpose of the XSPA profile is to address common needs: allow parties to
adopt a set of methods that, taken together, will enable them immediately
interoperate with other diverse participants in the same data exchanges; use
readily available open standards, so that participation is broadly possible
without significant licensing limitations, hardware or software choice
constraints or single-source vendor risks; and provide a fully specified stack
or set of specifications or options, all known to be interoperable. The
foregoing needs are especially acute when the use of a particular set of methods
is mandated, either by law or as a practical matter by its adoption by central
actors in a mandatory system.
Governmental health regulators are increasingly requiring certain parties
exchange health and health payment information (such as personal health records,
and itemize statements of health care charges and benefit payments) in
electronic form, and use sets of data standards identified as broadly suitable
and secure. Similar government-sponsored or government-encouraged
standardization projects are underway in many other countries. The XSPA profile
will provide another "building block" in the creation of large scale
interoperability of health information. These profiles will also aid in
achieving interoperability for secure data exchange among various health care
entities including providers, hospitals, pharmacies and insurance companies. It
is envisioned that the work produced by this committee will also help the
National Health Information Network (NHIN) in the US for secure data exchange.
It specifying the XSPA profile, where stable open standards exist, they should
be noted and adopted. Where functions are not available, or some connective
choices or additional material is required, it will be created. Doing so is the
purpose for this committee's creation.
The profile specified by this TC will have broad applicability to health
communities beyond the regulated portion of U.S. healthcare data transactions
that the HITSP panel is directed to address. Use cases from other instances of
cognate data exchanges, particularly in healthcare privacy contexts, may be
solicited and used to improve the TC's work. However, the first priority of
this committee will be to deliver and demonstrate sets of standards-based
methods that fulfill the identified security & privacy functions needed by
HITSP's specifications of functions and mandates.
The XSPA TC may also cover a more general enterprise server profile which will
provide the building blocks for business models and industry applications. Some
of the models investigated will include enterprise security and more generally
SOA security. Application of how these security and privacy models apply to
different industry sectors, including domains such as finance where privacy
rights must be supported, will also be investigated if time permits.
1c. Scope
The purpose of the TC is to specify sets of stable open standards and profiles,
and create other standards or profiles as needed, to fulfill the security and
privacy functions identified by the functions and data practices identified by
HITSP, or specified in its use cases, as all are mandated or specified from time
to time. These functions will at a minimum support the HITSP Access Control
Transaction Package specification TP20, including those access control
capabilities required to support the HITSP Manage Consent Directive Package
specification TP30. This includes the support of reliable and auditable methods
to identify, select and confirm the personal identity, official authorization
status, and role data for the subjects, senders, receivers and intermediaries of
electronic data; data needed to convey and/or enforce permitted operations on
resources and associated conditions and obligations; and reasonable measures to
secure and maintain the privacy and integrity of that data from end to end.
1. The TC may identify existing, stable open standards, and sets of standards,
and alternative standards, extensions and profiles, for fulfilling each of the
HITSP-identified functions and use cases. Where HITSP subject-matter-specific
profiles have already identified such standards as recommended, those approved
standards will be included in the TC's identified sets of standards. Where the
TC identifies elements or alternatives not already so identified as recommended,
the TC should, if it believes the additional alternatives are necessary or
advisable, recommend their inclusion to the appropriate HITSP expert panel.
2. The TC may create and approve specifications, and extensions or profiles of
specifications, as needed to fulfill HITSP-identified functions and use cases
not satisfied by existing stable open standards. Contributions made to the
committee for work issued by the committee itself will be subject to the OASIS
IPR Policy. Any such work must include appropriate conformance clause or test
information. Such work will be recommended for inclusion, as appropriate, in
the standing recommendations of the appropriate HITSP expert panel.
3. The TC may elect, in the above specifications, extensions or profile, to
indicate methods for the fulfillment of other publicly-available health-related
use cases (or mandates), or functions described in those use cases (or
mandates), including from other regions and other regulatory regimes; and may
elect to create and approve additional specifications, and extensions or
profiles of specifications, as needed, to fulfill those use cases or component
functions.
4. The TC may elect to elaborate or extend any of the above use cases or
functions, publish the same and create additional standards, profiles or
extensions to support those augmented use cases or functional descriptions. In
any such augmented work the TC must specify whether it is intended to fulfill an
HITSP (or other) mandate. Any such work must include appropriate conformance
clause or test information. Such work completed may be recommended for
inclusion, as appropriate, in the recommendations or reports of any relevant
health regulatory or advisory body.
5. The TC may elect to create supplemental information regarding the above
matters such as demonstrations, implementation guides, best practices, FAQs, or
other explanatory, implementation or promotional material as it may deem useful.
6. In all of its work, the TC should, to the extent feasible, prefer widely
implementable, widely interoperable, modular standards, extensions, profiles and
methods that permit use by a variety of participants with diverse hardware,
software, data architecture and messaging practices. The TC intends to ask
OASIS to contribute all or part of its final work, as relevant, HITSP or related
panels for incorporation into its recommendations and mandates.
1d. List of Deliverables
1. A list of the specific HITSP use cases and functions that the TC plans to
fulfill, by October 2008.
2. A set of specifications, sets, profiles and extensions, as described in
paragraphs #1 and #2 under 'Scope', to fulfill each of the HITSP use cases and
functions identified for fulfillment in deliverable paragraph #1, with the first
such specification or profile to be approved as a Committee Specification by
[December 2008], and the remainder if any to be approved by Committee
Specifications by [June 2009]. The TC may elect to create one or more of such
deliverables in whatever combinations it deems appropriate.
3. An interoperability demonstration of the XSPA profile, consistent with
paragraph #5 under 'Scope,' demonstrating the end-to-end enforcement of
healthcare security policy at the HIMSS (Healthcare Information and Management
Systems Society) meeting (April 2009).
4. Optionally, such other deliverables (e.g., those listed in paragraphs 1-6
under 'Scope') as the TC may elect, until the later of December 2009 or such
later date as the TC may elect to conclude.
1e. IPR Mode:
Royalty Free on Limited Terms under the OASIS IPR Policy
1f. Anticipated Audiences:
Health-related data transaction participants, especially in exchanges subject to
security or privacy regulation; regulators of healthcare, health payment and
personal privacy; vendors and integrators supplying products or services to the
foregoing; and, secondarily, participants in regulated or closely monitored
data exchanges with privacy and security requirements in other topical fields.
1g. Language:
English
(2) Non-normative information regarding the startup of the TC, which includes:
(2)(a) Identification of similar or applicable work that is being done in other
OASIS TCs or by other organizations, why there is a need for another effort in
this area and how this proposed TC will be different, and what level of liaison
will be pursued with these other organizations.
The proposed Cross-Enterprise Security and Privacy Authorization (XSPA) TC will
be incorporating several standards in a profile allowing the exchange of privacy
policies, consent directives and authorizations in an interoperable manner. The
need for an XSPA profile has been identified by the security and privacy working
group of the ANSI-sponsored Healthcare Information Technology Standards Panel
(HITSP). No other organization is addressing this identified gap in standards.
The profile will use standards from several OASIS TCs: SAML (SSTC), WS-Trust
(WS-SX) and XACML. Liaison will be established by concurrent work items in the
cited TCs' area of expertise.
(2)(b) The date, time, and location of the first meeting, whether it will be
held in person or by telephone, and who will sponsor this first meeting. The
first meeting of a TC shall occur no less than 30 days after the announcement of
its formation in the case of a meeting held exclusively by telephone or other
electronic means, and no less than 45 days after the announcement of its
formation in the case of a meeting held face-to-face (whether or not a telephone
bridge is also available).
The proposed XSPA TC will hold the first official meeting on August 8, 2008 by
telephone and will use a free conference call service.
(2)(c) The projected on-going meeting schedule for the year following the
formation of the TC, or until the projected date of the final deliverable,
whichever comes first, and who will be expected to sponsor these meetings.
The TC will meet biweekly or as otherwise agreed upon by the members of the
technical committee.
(2)(d) The names, electronic mail addresses, and membership affiliations of at
least Minimum Membership who support this proposal and are committed to the
Charter and projected meeting schedule.
Mark Little (Redhat)
Anil Saldhana (Redhat)
Sampo Kellomki (Symlabs)
Anil Tappetla (Cisco)
David Staggs (Veterans Health Administration)
(2)(e) The name of the Convener who must be an Eligible Person.
David Staggs.
(2)(f) The name of the Member Section with which the TC intends to affiliate, if
any.
None.
(2)(g) Optionally, a list of contributions of existing technical work that the
proposers anticipate will be made to this TC.
None.
(2)(h) Optionally, a draft Frequently Asked Questions (FAQ) document regarding
the planned scope of the TC, for posting on the TC's website.
To be provided at a later date.
(2)(i) Optionally, a proposed working title and acronym for the specification(s)
to be developed by the TC.
To be provided at a later date.
=============================================================================
I strongly feel that this TC is a great step toward health care security.
Saturday, April 12, 2008
Summary Review: Oasis XACML Interoperability Event at the RSA Conference 2008
Now that the RSA Conference 2008 has finished in San Francisco, I would like to take some time to inform you about the grand success of the Oasis XACML Interoperability event with JBoss/RedHat and other interoperability participants namely BEA Systems, IBM, Oracle, Sun, Axiomatics, Cisco and Department of Veteran Affairs.
Information from the Oasis site is here.
The press release for the event from Oasis is here.
The code that has undergone two successful consecutive Oasis XACML Interoperability Event will be soon (matter of days) as JBossXACML v2.0.2.GA. The pending item is some documentation on usage. This library will also be included in the JBoss AS 5.0 to provide xacml capabilities.
References:
1) PolicySets used in the interop.
2) Tests used for the interop.
Details:
In a nutshell, XACML is a language focused solely on Access Control. All it does is Access Control and nothing else. Given this, at the interoperability event, the VA folks came out with health care scenarios associated with Patient Privacy. There are HL7 Confidentiality Codes that can be associated with Patient medical records.
Let me give some examples:
1) Your neighbor is a doctor and is snoopy in nature. You certainly do not want him to have access to your medical records. Would you? As a patient, you can associate the UBA confidentiality code with a list of doctors that you do not want to have access to your records (dissent list).
2) A patient arrives at a facility in an emergency. The providers do not have access to the patient records that is housed at another facility. They can trigger an "emergency override" to get access to the records. Shouldn't they in an emergency?
3) A patient can decide to mask a portion of his medical records (eg. radiology tests ' results) from a list of providers.
The VA developed an excellent application that had a decent GUI and in the background, it interacted with its own PIP (Policy Information Point) to derive the attributes needed to create the XACML requests. Once the xacml requests were generated (based on the application interaction), then they were passed to the PDP (Policy Decision Point) of the vendors.
Summary:
A simulated health care application with real medical records' data that was driven by xacml based use cases.
Additional References:
Oasis XACML Interoperability Document Bundle
^^^^^ (VERY IMPORTANT RESOURCE) ^^^^
Samples:
The following are examples of SAML2 payload carrying XACML request/responses.
Here is a sample of the request coming from the health care web application to back end PDP.
Now a sample of a response (which does include the xacml request for which the response is)
Reference:
Oasis XACML Interoperability (RSA Conference 2008)
NOTE:If you need additional info, do not hesistate to email me at "asaldhan at redhat dot com" <======
Information from the Oasis site is here.
The press release for the event from Oasis is here.
The code that has undergone two successful consecutive Oasis XACML Interoperability Event will be soon (matter of days) as JBossXACML v2.0.2.GA. The pending item is some documentation on usage. This library will also be included in the JBoss AS 5.0 to provide xacml capabilities.
References:
1) PolicySets used in the interop.
2) Tests used for the interop.
Details:
In a nutshell, XACML is a language focused solely on Access Control. All it does is Access Control and nothing else. Given this, at the interoperability event, the VA folks came out with health care scenarios associated with Patient Privacy. There are HL7 Confidentiality Codes that can be associated with Patient medical records.
Let me give some examples:
1) Your neighbor is a doctor and is snoopy in nature. You certainly do not want him to have access to your medical records. Would you? As a patient, you can associate the UBA confidentiality code with a list of doctors that you do not want to have access to your records (dissent list).
2) A patient arrives at a facility in an emergency. The providers do not have access to the patient records that is housed at another facility. They can trigger an "emergency override" to get access to the records. Shouldn't they in an emergency?
3) A patient can decide to mask a portion of his medical records (eg. radiology tests ' results) from a list of providers.
The VA developed an excellent application that had a decent GUI and in the background, it interacted with its own PIP (Policy Information Point) to derive the attributes needed to create the XACML requests. Once the xacml requests were generated (based on the application interaction), then they were passed to the PDP (Policy Decision Point) of the vendors.
Summary:
A simulated health care application with real medical records' data that was driven by xacml based use cases.
Additional References:
Oasis XACML Interoperability Document Bundle
^^^^^ (VERY IMPORTANT RESOURCE) ^^^^
Samples:
The following are examples of SAML2 payload carrying XACML request/responses.
Here is a sample of the request coming from the health care web application to back end PDP.
<?xml version="1.0" encoding="UTF-8"?> <samlp:RequestAbstract Destination="destination-uri" ID="s2846efb514a944cc3dc5b65ed8a76dde449787617" IssueInstant="2008-03-19T22:18:42Z" Version="2.0" xacml-samlp:InputContextOnly="true" xacml-samlp:ReturnContext="true" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xacml-samlp="urn:oasis:xacml:2.0:saml:protocol:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xacml-samlp:XACMLAuthzDecisionQueryType"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">vaPepEntity</saml:Issuer> <xacml-context:Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os http://docs.oasis-open.org/xacml/access_control-xacml-2.0-context-schema-os.xsd"> <xacml-context:Subject> <xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>Dr. Alice</xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:va:xacml:2.0:interop:rsa8:subject:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-003 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-005 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-006 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-009 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-010 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-012 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-017 </xacml-context:AttributeValue> </xacml-context:Attribute> </xacml-context:Subject> <xacml-context:Resource> <xacml-context:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource: resource-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>Anthony Gurrola</xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:va:xacml:2.0:interop:rsa8:resource:hl7:permission" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-003 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-005 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-006 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-009 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-010 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-012 </xacml-context:AttributeValue> <xacml-context:AttributeValue>urn:va:xacml:2.0:interop:rsa8:hl7:prd-017 </xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:va:xacml:2.0:interop:rsa8:resource:hl7:confidentiality-code" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>xxx-DummyConfCode</xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:va:xacml:2.0:interop:rsa8:resource:hl7:dissented-subject-id" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>Dr. Alice</xacml-context:AttributeValue> </xacml-context:Attribute> <xacml-context:Attribute AttributeId="urn:va:xacml:2.0:interop:rsa8:resource:hl7:type" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue> urn:va:xacml:2.0:interop:rsa8:resource:hl7:medical-record</xacml-context:AttributeValue> </xacml-context:Attribute> </xacml-context:Resource> <xacml-context:Action/> <xacml-context:Environment> <xacml-context:Attribute AttributeId="urn:va:xacml:2.0:interop:rsa8:environment:locality" DataType="http://www.w3.org/2001/XMLSchema#string"> <xacml-context:AttributeValue>Facility A</xacml-context:AttributeValue> </xacml-context:Attribute> </xacml-context:Environment> </xacml-context:Request> </samlp:RequestAbstract>
Now a sample of a response (which does include the xacml request for which the response is)
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="response-id:1" Version="2.0" IssueInstant="2008-03-19T22:17:13Z"> <samlp:Status xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <samlp:StatusCode xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Value="urn:oasis:names:tc:xacml:1.0:status:ok"> </samlp:StatusCode> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0" ID="response-id:1" IssueInstant="2008-03-19T22:17:13Z"> <saml:Issuer>issuer-1</saml:Issuer> <saml:Statement xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xsi:type="xacml-samlp:XACMLAuthzDecisionStatementType" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xacml-samlp="urn:oasis:xacml:2.0:saml:protocol:schema:os" xmlns:xacml-saml="urn:oasis:names:tc:xacml:2.0:saml:assertion:schema:os" > <xacml-context:Response xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os" > <xacml-context:Result > <xacml-context:Decision>Permit</xacml-context:Decision> <xacml-context:Status> <xacml-context:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"></xacml-context:StatusCode> <xacml-context:StatusMessage>ok</xacml-context:StatusMessage> </xacml-context:Status> <xacml:Obligations xmlns:xacml="urn:oasis:names:tc:xacml:2.0:policy:schema:os" > <xacml:Obligation ObligationId="obligation-10" FulfillOn="Permit"> </xacml:Obligation> <xacml:Obligation ObligationId="obligation-20" FulfillOn="Permit"> <xacml:AttributeAssignment AttributeId="a-120" DataType="http://www.w3.org/2001/XMLSchema#string" xmlns:xacml="urn:oasis:names:tc:xacml:2.0:policy:schema:os"/> </xacml:Obligation> </xacml:Obligations> </xacml-context:Result> </xacml-context:Response> <xacml-context:Request xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance/" xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os http://docs.oasis-open.org/xacml/access_control-xacml-2.0-context-schema-os.xsd"> <Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="http://www.w3.org/2001/XMLSchema#string" > <AttributeValue>100001</AttributeValue> </Attribute> <Attribute AttributeId="urn:va:names:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string" > <AttributeValue>Chief Resident</AttributeValue> <AttributeValue>Doctor</AttributeValue> </Attribute> <Attribute AttributeId="urn:va:names:xacml:2.0:subject:hl7permission" DataType="http://www.w3.org/2001/XMLSchema#string" > <AttributeValue>PRD-017</AttributeValue> <AttributeValue>PRD-003</AttributeValue> <AttributeValue>PRD-010</AttributeValue> <AttributeValue>PRD-006</AttributeValue> </Attribute> <Attribute AttributeId="urn:va:names:xacml:2.0:subject:locality" DataType="http://www.w3.org/2001/XMLSchema#string" > <AttributeValue>Facility A</AttributeValue> </Attribute> </Subject> <xacml-context:Resource> <Attribute AttributeId="urn:va:names:xacml:2.0:record_type" DataType="http://www.w3.org/2001/XMLSchema#string" > <AttributeValue>patientchart</AttributeValue> </Attribute> </xacml-context:Resource> <xacml-context:Action> <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#string" > <AttributeValue>read</AttributeValue> </Attribute> </xacml-context:Action> <xacml-context:Environment></xacml-context:Environment> </xacml-context:Request> </saml:Statement> </saml:Assertion> </samlp:Response>
Reference:
Oasis XACML Interoperability (RSA Conference 2008)
NOTE:If you need additional info, do not hesistate to email me at "asaldhan at redhat dot com" <======
Subscribe to:
Posts (Atom)