You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by Peter Abramowitsch <pa...@gmail.com> on 2020/09/24 21:01:57 UTC
Authentication update
Hi All
I managed to have a conversation with Patrick McLaughlin who's in charge of
the Authentication changes at UMLS. I have some updates for you which I
think you will find reassuring.
He's familiar with cTAKES but hasn't used it personally, nor was very
familiar with the different ways it could be deployed and its
authentication requirements.
To boil the conversation down to a few key points:
They want to get out of the business of forgotten password and username
management. but they are still creating individual user accounts and
accounts for content providers.
There are two routes to authenticating and I think the far simpler one for
traditional cTAKES users will be that of using API keys instead of an
external Authentication service. Strangely enough, I had to ask Patrick
about it since it is not mentioned on their recent emails to our
community. So I'll describe that approach first:
API_KEY Method.
Our individual user accounts do and will still have an API key created for
them and you can authenticate with the API key instead of username-password
to get an access token with a specific TTL. (a surrogate for yes/no
authentication) So cTAKES will need some relatively trivial changes to
accept an API key in the usual places (EnvVar, System Property, or
Piperfile) and then make the appropriate request with that key.
I'm using the alternate authentication URL property so I can relay requests
through a proxy authenticator, but it will forward API keys just as cTakes'
new code should do. So whoever makes these changes - please don't remove
the modifiable system property
* ctakes.umlsaddr !!*
What the UTS will want, though, is the domain name from which the API
bearing Token request will come, so they can whitelist it.
If you have no UMLS license yet, you will go to the UTS as usual to apply
and from there, you will be given the choice of several external sources of
identity verification. Here's where external authentication will come into
play (using Google Auth, Facebook, Login.gov etc): Once you've passed that
step, you'll get the user account and an API key.
If you already have a UMLS license and are using the username password
paradigm, when the cTAKES fix is out, go back to your UTS profile and find
your API key.
SECOND OPTION
(after your license is updated or newly established with whitelist &
callback info)
If you are architecting an implementation where ad-hoc users authenticate
for one-off interactions with cTakes through a website or directly with the
UMLS metathesaurus via its APIs, the implementation will involve something
more complicated. You will need to implement a publicly visible web
service or callback-link on your site.
Your authentication request will go out, probably with an email address and
will be forwarded by UTS to your authenticator of choice (whomever you
specified when creating your license)
Asynchronously, the UTS will call back on your registered URL which your
application will be listening for to give you approval or rejection. This
would unblock access to cTAKES or the website behind which you've deployed
it.
So you see that this method is not really suitable for situations where
cTAKES is used as a console app or a dedicated web-service, possibly
situated deep within a protected PHI safe zone. In this setting a
Synchronous authentication approach using the API_KEY would be simpler from
every angle.
If I haven't been clear enough or you still have questions, call Patrick.
He's very open to working with us
Peter
Re: Authentication update
Posted by Peter Abramowitsch <pa...@gmail.com>.
The correct answer would be no. Not in an out-of-the-box implementation of
cTAKES. Leaving a trail of our usage of UMLS is one of the factors
contributing to its very existence. If it seemed as if no-one were using
these validation APIs at UMLS - it would give ammunition to the budget
cutters.
You can do more-or-less whatever you want with software, so it is an
ethical question as much as a technical one.
An implementation such as ours has to go to some extra lengths to obtain a
user's credentials because the cTakes service is buried inside a PHI
sensitive zone that has no cloud-facing ports. But still, we do it.
Peter
On Thu, Sep 24, 2020 at 2:13 PM Akram <as...@yahoo.com.invalid> wrote:
> Thanks Peter,
> Is there a way we can use cTAKES completely offline?
> I mean we can download whatever we need from UMLS and use it as datasource
> locally in our computers?
>
>
>
> On Thursday, 24 September 2020, 02:02:15 pm GMT-7, Peter Abramowitsch <
> pabramowitsch@gmail.com> wrote:
>
> Hi All
>
> I managed to have a conversation with Patrick McLaughlin who's in charge of
> the Authentication changes at UMLS. I have some updates for you which I
> think you will find reassuring.
>
> He's familiar with cTAKES but hasn't used it personally, nor was very
> familiar with the different ways it could be deployed and its
> authentication requirements.
>
> To boil the conversation down to a few key points:
>
> They want to get out of the business of forgotten password and username
> management. but they are still creating individual user accounts and
> accounts for content providers.
>
> There are two routes to authenticating and I think the far simpler one for
> traditional cTAKES users will be that of using API keys instead of an
> external Authentication service. Strangely enough, I had to ask Patrick
> about it since it is not mentioned on their recent emails to our
> community. So I'll describe that approach first:
>
> API_KEY Method.
>
> Our individual user accounts do and will still have an API key created for
> them and you can authenticate with the API key instead of username-password
> to get an access token with a specific TTL. (a surrogate for yes/no
> authentication) So cTAKES will need some relatively trivial changes to
> accept an API key in the usual places (EnvVar, System Property, or
> Piperfile) and then make the appropriate request with that key.
>
> I'm using the alternate authentication URL property so I can relay requests
> through a proxy authenticator, but it will forward API keys just as cTakes'
> new code should do. So whoever makes these changes - please don't remove
> the modifiable system property
> * ctakes.umlsaddr !!*
>
> What the UTS will want, though, is the domain name from which the API
> bearing Token request will come, so they can whitelist it.
>
> If you have no UMLS license yet, you will go to the UTS as usual to apply
> and from there, you will be given the choice of several external sources of
> identity verification. Here's where external authentication will come into
> play (using Google Auth, Facebook, Login.gov etc): Once you've passed that
> step, you'll get the user account and an API key.
>
> If you already have a UMLS license and are using the username password
> paradigm, when the cTAKES fix is out, go back to your UTS profile and find
> your API key.
>
> SECOND OPTION
> (after your license is updated or newly established with whitelist &
> callback info)
>
> If you are architecting an implementation where ad-hoc users authenticate
> for one-off interactions with cTakes through a website or directly with the
> UMLS metathesaurus via its APIs, the implementation will involve something
> more complicated. You will need to implement a publicly visible web
> service or callback-link on your site.
>
> Your authentication request will go out, probably with an email address and
> will be forwarded by UTS to your authenticator of choice (whomever you
> specified when creating your license)
>
> Asynchronously, the UTS will call back on your registered URL which your
> application will be listening for to give you approval or rejection. This
> would unblock access to cTAKES or the website behind which you've deployed
> it.
>
> So you see that this method is not really suitable for situations where
> cTAKES is used as a console app or a dedicated web-service, possibly
> situated deep within a protected PHI safe zone. In this setting a
> Synchronous authentication approach using the API_KEY would be simpler from
> every angle.
>
> If I haven't been clear enough or you still have questions, call Patrick.
> He's very open to working with us
>
> Peter
>
Re: Authentication update
Posted by Akram <as...@yahoo.com.INVALID>.
Thanks Peter,
Is there a way we can use cTAKES completely offline?
I mean we can download whatever we need from UMLS and use it as datasource locally in our computers?
On Thursday, 24 September 2020, 02:02:15 pm GMT-7, Peter Abramowitsch <pa...@gmail.com> wrote:
Hi All
I managed to have a conversation with Patrick McLaughlin who's in charge of
the Authentication changes at UMLS. I have some updates for you which I
think you will find reassuring.
He's familiar with cTAKES but hasn't used it personally, nor was very
familiar with the different ways it could be deployed and its
authentication requirements.
To boil the conversation down to a few key points:
They want to get out of the business of forgotten password and username
management. but they are still creating individual user accounts and
accounts for content providers.
There are two routes to authenticating and I think the far simpler one for
traditional cTAKES users will be that of using API keys instead of an
external Authentication service. Strangely enough, I had to ask Patrick
about it since it is not mentioned on their recent emails to our
community. So I'll describe that approach first:
API_KEY Method.
Our individual user accounts do and will still have an API key created for
them and you can authenticate with the API key instead of username-password
to get an access token with a specific TTL. (a surrogate for yes/no
authentication) So cTAKES will need some relatively trivial changes to
accept an API key in the usual places (EnvVar, System Property, or
Piperfile) and then make the appropriate request with that key.
I'm using the alternate authentication URL property so I can relay requests
through a proxy authenticator, but it will forward API keys just as cTakes'
new code should do. So whoever makes these changes - please don't remove
the modifiable system property
* ctakes.umlsaddr !!*
What the UTS will want, though, is the domain name from which the API
bearing Token request will come, so they can whitelist it.
If you have no UMLS license yet, you will go to the UTS as usual to apply
and from there, you will be given the choice of several external sources of
identity verification. Here's where external authentication will come into
play (using Google Auth, Facebook, Login.gov etc): Once you've passed that
step, you'll get the user account and an API key.
If you already have a UMLS license and are using the username password
paradigm, when the cTAKES fix is out, go back to your UTS profile and find
your API key.
SECOND OPTION
(after your license is updated or newly established with whitelist &
callback info)
If you are architecting an implementation where ad-hoc users authenticate
for one-off interactions with cTakes through a website or directly with the
UMLS metathesaurus via its APIs, the implementation will involve something
more complicated. You will need to implement a publicly visible web
service or callback-link on your site.
Your authentication request will go out, probably with an email address and
will be forwarded by UTS to your authenticator of choice (whomever you
specified when creating your license)
Asynchronously, the UTS will call back on your registered URL which your
application will be listening for to give you approval or rejection. This
would unblock access to cTAKES or the website behind which you've deployed
it.
So you see that this method is not really suitable for situations where
cTAKES is used as a console app or a dedicated web-service, possibly
situated deep within a protected PHI safe zone. In this setting a
Synchronous authentication approach using the API_KEY would be simpler from
every angle.
If I haven't been clear enough or you still have questions, call Patrick.
He's very open to working with us
Peter
Re: Authentication update [EXTERNAL]
Posted by "Finan, Sean" <Se...@childrens.harvard.edu>.
This is some fantastic information! Thank you for being so thorough and thank you so much for reaching out to Patrick McLaughlin!
The next time I am in SF I will buy you a beer, coffee, toffee, whatever.
Sean
________________________________________
From: Peter Abramowitsch <pa...@gmail.com>
Sent: Thursday, September 24, 2020 5:01 PM
To: dev@ctakes.apache.org
Subject: Authentication update [EXTERNAL]
* External Email - Caution *
Hi All
I managed to have a conversation with Patrick McLaughlin who's in charge of
the Authentication changes at UMLS. I have some updates for you which I
think you will find reassuring.
He's familiar with cTAKES but hasn't used it personally, nor was very
familiar with the different ways it could be deployed and its
authentication requirements.
To boil the conversation down to a few key points:
They want to get out of the business of forgotten password and username
management. but they are still creating individual user accounts and
accounts for content providers.
There are two routes to authenticating and I think the far simpler one for
traditional cTAKES users will be that of using API keys instead of an
external Authentication service. Strangely enough, I had to ask Patrick
about it since it is not mentioned on their recent emails to our
community. So I'll describe that approach first:
API_KEY Method.
Our individual user accounts do and will still have an API key created for
them and you can authenticate with the API key instead of username-password
to get an access token with a specific TTL. (a surrogate for yes/no
authentication) So cTAKES will need some relatively trivial changes to
accept an API key in the usual places (EnvVar, System Property, or
Piperfile) and then make the appropriate request with that key.
I'm using the alternate authentication URL property so I can relay requests
through a proxy authenticator, but it will forward API keys just as cTakes'
new code should do. So whoever makes these changes - please don't remove
the modifiable system property
* ctakes.umlsaddr !!*
What the UTS will want, though, is the domain name from which the API
bearing Token request will come, so they can whitelist it.
If you have no UMLS license yet, you will go to the UTS as usual to apply
and from there, you will be given the choice of several external sources of
identity verification. Here's where external authentication will come into
play (using Google Auth, Facebook, Login.gov etc): Once you've passed that
step, you'll get the user account and an API key.
If you already have a UMLS license and are using the username password
paradigm, when the cTAKES fix is out, go back to your UTS profile and find
your API key.
SECOND OPTION
(after your license is updated or newly established with whitelist &
callback info)
If you are architecting an implementation where ad-hoc users authenticate
for one-off interactions with cTakes through a website or directly with the
UMLS metathesaurus via its APIs, the implementation will involve something
more complicated. You will need to implement a publicly visible web
service or callback-link on your site.
Your authentication request will go out, probably with an email address and
will be forwarded by UTS to your authenticator of choice (whomever you
specified when creating your license)
Asynchronously, the UTS will call back on your registered URL which your
application will be listening for to give you approval or rejection. This
would unblock access to cTAKES or the website behind which you've deployed
it.
So you see that this method is not really suitable for situations where
cTAKES is used as a console app or a dedicated web-service, possibly
situated deep within a protected PHI safe zone. In this setting a
Synchronous authentication approach using the API_KEY would be simpler from
every angle.
If I haven't been clear enough or you still have questions, call Patrick.
He's very open to working with us
Peter