[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[higgins-dev] FW: [ohf-dev] The future of ohf-dev
|
Higginsvolk,
You may want to have a chat with your colleagues in the OHF project.
-----Original Message-----
From: ohf-dev-bounces@xxxxxxxxxxx [mailto:ohf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Grahame Grieve
Sent: Thursday, March 08, 2007 6:38 PM
To: sdoyle@xxxxxxxxxxxxxx; Open Healthcare Framework Mailing list
Subject: Re: [ohf-dev] The future of ohf-dev
Hi Sean
We are keen to have further discussions with you in
regard to this - we are planning to work on security
this year.
There is already a project with some SAML implementation
in Eclipse, which is higgins (http://www.eclipse.org/higgins).
We would need to collaborate with higgins on this matter.
Don Jorgenson is going to work with you and Higgins on this.
Grahame
Sean Doyle wrote:
> ---------- Forwarded message ----------
> From: Sean Doyle <sdoyle.backup@xxxxxxxxx>
> Date: Mar 7, 2007 1:53 PM
> Subject: Re: [ohf-dev] The future of ohf-dev
> To: mike.milinkovich@xxxxxxxxxxx, Open Healthcare Framework Mailing list <
> ohf-dev@xxxxxxxxxxx>
>
> I'm very much interested in security, privacy, and consent issues. I'm not
> sure how to link this into the current conversation because I'm not
familar
> with OGSI - maybe it's how broadly we define the security framework we're
> discussing here.
>
> At HIMSS I was demonstrating how you could use single sign on with
> Liberty/SAML 2.0 and we have the start of the ability to put SAML
> assertions
> into SOAP headers we use for communcating with our server to identify the
> sender of the message. I'm still on a learning curve about SAML; I know we
> need to be open to Shibboleth and perhaps other identity frameworks as
> well.
> I think that interoperability needs to be defined on this level rather
than
> in the J2EE/OSGI level.
>
> Once we have identity- we can specify consents to some degree using XACML
> embedded in the SAML assertions. There's plenty of work to be done here
> about how to set up a taxonomy of the different data elements being
> referred
> to in the XACML statements for access rules - I'm hoping that if these can
> be wrapped in a clear enough manner that this becomes the mechanism by
> which
> patient consent can be implemented ( e.g. - some rendering of the XACML
can
> be understood by and agreed to by the patient).
>
> There's lots of issues there too about where these XACML statements are
> stored (a Liberty People Service? I'm sure there's lots of other
approaches
> too).
>
> I believe that IHE is going to be specifying SAML 2.0 assertions in XDS
> client transactions in this next year via the XUA protocol. I don't know
of
> any plans to extend this to non-XDS profiles yet.
>
> If the interpreters for the SAML and XACML are OSGI or J2EE components for
> OHF - then I see how this fits together. There would need to be some
> security objects that would store things like how the user was
> authenticated
> and by whom; session identifiers so that you could support a distributed
> logout; stuff like that. SAML assertions generated by an IdP should be
> passed as pojos to the XDS client. But I might be missing the point
> entirely
> & would welcome a correction.
>
> Sorry I didn't make it to EclispeCon - it would have been great to discuss
> this in front of a whiteboard.
>
> Thanks
>
> Sean
>
> On 3/7/07, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxx> wrote:
>>
>> Because of my personal time constraints here at EclipseCon, it is
>> going to
>> be hard to give this thread the response it deserves today. I want to
>> make
>> it clear that I'm listening and that I will endeavor to post a coherent
>> response shortly.
>>
>> Mike Milinkovich
>> Office: +1.613.224.9461 x228
>> Mobile: +1.613.220.3223
>> mike.milinkovich@xxxxxxxxxxx
>>
>>
>> > -----Original Message-----
>> > From: Terrell Deppe [mailto: Terrell.Deppe@xxxxxxxxxx]
>> > Sent: Wednesday, March 07, 2007 10:17 AM
>> > To: grahame@xxxxxxxxxxxxxxx; Open Healthcare Framework Mailing list;
>> > Mike Milinkovich; Open Healthcare Framework Mailing list
>> > Cc: Bjorn Freeman-Benson; Skip McGaughey; Ward Cunningham
>> > Subject: RE: [ohf-dev] The future of ohf-dev
>> >
>> > As a potential OHF contributor, we are watching this very carefully. It
>> > appears that OSGi is being positioned as revolt against Enterprise
>> > Java. That's not surprising to me considering the current state of
>> > Websphere. The issues that you have outlined, security in particular,
>> > are already solved in the J2EE and Java EE 5.
>> >
>> > Interoperability of HIS components in particular should rightfully
>> > reside on the server where they can live in a cluster, and take
>> > advantage of load balancing. OSGi on the client makes sense, but my
>> > colleagues and I are struggling with the idea of OSGi on the server. We
>> > don't see what that buys us.
>> >
>> > One solution that we've tossed around is that since the OHF business
>> > logic is POJO, you could continue to develop and test in the OSGi space
>> > on the desktop. Those same POJOs could also be fronted with an SLSB for
>> > an enterprise solution.
>> >
>> > Can someone explain why OSGi is being presented here at EclipseCon as a
>> > magic pill to cure all ills? Neo?
>> >
>> >
>> > -----Original Message-----
>> > From: ohf-dev-bounces@xxxxxxxxxxx on behalf of Grahame Grieve
>> > Sent: Wed 3/7/2007 12:08 AM
>> > To: Mike Milinkovich; Open Healthcare Framework Mailing list
>> > Cc: Bjorn Freeman-Benson; Skip McGaughey; Ward Cunningham
>> > Subject: [ohf-dev] The future of ohf-dev
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> ohf-dev mailing list
>> ohf-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ohf-dev
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ohf-dev mailing list
> ohf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ohf-dev
--
Grahame Grieve
CTO, Jiva Medical Software Integration Tools
CTO, Kestral Computing Healthcare Applications
_______________________________________________
ohf-dev mailing list
ohf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ohf-dev
