UDAP Springboot

[Brett Stringham]

I would like to contribute a UDAP implementation to be founded upon Springboot -- which is where most of my time has been invested in recent years. With Joe S. blazing trails on the .NET implementation, I must catch-up so the Java community doesn't feel left out;)

For now, I'm focusing initially on Trusted DCR and would like to vet the Springboot implementation with tests @ https://www.udap.org/UDAPTestTool/

With the above it mind, would it be possible to get an issued certificate?

Thanks!

Brett Stringham

[Joseph Shook]

Very cool!  I imagine this would include some type of interceptor to by plugged into Hapi Server?  I am interested in something along this line as are the National Directory friends.  I surely would offer help here as needed.  

[Dan Cinnamon]

Great Brett- welcome to the party! Would be great to cross-test with you as you build out your platform.  Are you looking to offer a server, client, or both?

[Brett Stringham]

Greetings Dan...I recall you from prior connectathon prep calls (last year).

My current focus is client side with the intention to also implement server side.

With a final target state consisting of Spring compatible components that enable UDAP to be reasonably plugged into springboot apps.

Doing cross-testing with you would be great.

--
You received this message because you are subscribed to a topic in the Google Groups "UDAP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/udap-discuss/eeW5wrhn5Ds/unsubscribe.
To unsubscribe from this group and all its topics, send an email to udap-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/udap-discuss/4707fd0f-b163-48f2-a5ab-505c317ca0afn%40googlegroups.com.

[Brett Stringham]

Yes -- that's an exceptional idea. I haven't dug too deep into the HAPI Java code yet, but would definitely enjoy working w/ you to make that interceptor come to life.

[Joseph Shook]

I am at the point where I could work on a HAPI interceptor to host a /.well-known/udap metadata endpoint.  Which is step one.  Step two would be to an interceptor for authentication challenge and authorization checks.  

I thought maybe Dan and Tom worked on something in HAPI?  Maybe not. 

BTW Dan and Tom my RI now supports the authorization_code grant type flow.  I will update the spread sheet so you could test against it.  

I have a new tool that is turning out to be a handy educational tool for presenting the mecanics of trusted DCR.   I think a demo would be in order to see what you all think and where I could take it next.  

[Dan Cinnamon]

Awesome Joe- I'll give the auth code flow a try on your server and let you know how it goes!

For the HAPI part of it- I guess the real answer is yes/no :). I basically created an outright proxy that sits completely in front of any FHIR service: https://github.com/dancinnamon-okta/secured-fhir-proxy

The FHIR server that I used in the connectathon is this- and yes behind the scenes I am proxying to a HAPI server.

A few other concepts about it of note:

- I made the proxy "multi-tenant" so it can host multiple .well-known/udap files, it can host multiple smart-configuration files, point to multiple actual FHIR servers, etc.  I got tired of spinning up so many implementations for testing smart/udap/smartv2/payer-payer/etc- so the idea here is to just have one that I can add "tenants" to.  It's pretty rough, but it's been good enough for the connectathon at least.

- I am also using this as a test bed for "fine grained authorization".  I have some coarse grained authz checks in there for patient/, user/, system/ scopes, but I'm also beginning to test out/explore more fine grained checks for the user/ and system/ scopes using openfga (openfga.dev)- which is essentially a relationship store. So in theory if a nurse were to login and get a user/ scope- there'd be a way to know which subset of patient records they can actually see, and furthermore what stuff within the patient record.  

The last one is a very new area for me, and one that I've seen people struggle with.  I'd really like to collaborate with the community to figure out at least a decent starting point on finer grained authorization that can be used to help people get started!

[Joseph Shook]

Wow!  I just started looking at the Github repo for openfga and I think I am going to lose this day to looking at that tech.  There is a dotnet-sdk also. I remember you chatting a bit about it a connect-a-thon.  I was heads down and not ready to digest it.

I am also going to head down the UDAP proxy path so I can test multiple FHIR servers.  

Yes the fine grained control in this context will be new to me also.  I am not sure how the proxy will fair in real world FHIR servers that already have fine grained control or don't.  

- HAPI doesn't have an example to experiment with that I know of.  We have to build it :(.  

- I have build and ran FHIR Server for Azure locally once.  It is a difficult code base to understand.  Seems very tied to AzureAD.  It would take a lot more time to disect it to the point of understanding where an abstraction point to integrate UDAP is.  But the reality in something like Azure the opinion of fine grained authorization is in place? (not an authority on any of this)  

- Then there is also the Firely evaluation server.  I have not looked at this and how I could host UDAP metadata and fined grain control.  They are a dotnet shop and are looking to implment UDAP also.  Hoping to collaborate with them.  

- Then looking at other things I might proxy, Epic comes to mind.  They also defind scopes and have a way to control this.  Again the proxy would be subject to the scopes picked for that application connection.   

Anyway as we get the UDAP implementations functional (and refactoring for some time) it seems an RI of fine grained access is where the big labor may be.  

Actually the HL7 B2B Authorization Extension Object as the "extensions" for client_assertion claim for client_credentials is the declaration during registration to provide additional information regarding the context under the request for data is authorized.  I have not thought this through.  

- Dan have you done anything with B2B Authorization Extension Object?

And then there is Certifications at registration time.  We could use a couple sample use cases to evolve how we might respond to certifications.  Would a certification be an asertion that would effect scopes and fine grained authorization?  

I guess I hijacked the Springboot topic.  

[Dan Cinnamon]

Yeah really excited to start some RI work on fine grained authorization- fully realizing that some (or even many) organizations will already have an implementation in their FHIR server. From my admittedly limited experience it appears there are enough servers out there that haven't implemented FGA that would at least make it worth some reference material- a starting point for the community. 

I was looking quick at the Azure FHIR server you referenced- it looks like it does coarse grained authorization today, with a few different coarse models for access:

https://github.com/microsoft/fhir-server/blob/main/src/Microsoft.Health.Fhir.Core/Features/Security/Authorization

So it's a nice start for sure (and it's bundled to be easily added to- I could imagine an openFGA call in there in a similar implementation).

I haven't played around much with the extension objects yet- however I would say that this topic does expose some logical separation of concerns.  The B2B extension object is sent by the client to the authorization server, which could then have policy around what scopes are granted when minting an access token. The token that is sent to the FHIR server is the one that the authorization server minted, and doesn't necessarily have the B2B extension object within it (the token format is not standardized). So unless we make some more assertions about the access token format and content, the FHIR server likely wont have access to the extension object for use in FGA.