Security: HealthIntersections/fhirserver

Security

Report a vulnerability

security.md

FHIRServer Security

This page documents the FHIR Server security.

Principles

The Full FHIRServer offers 2 interfaces: secure, and insecure. They both have exactly the same functionality, which is what is described in the FHIR Specification. However, on the secure interface, clients have to authenticate. Note that there are 2 different meanings to authenticate:

  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of

Finally, there is authorization - determining what actions the user authorizes the software to take on their behalf.

Insecure Interface

This is s a non-SSL interface to the server. it is provided for user convenience. The main convenience is that it is is easy to snoop on the traffic, or use simpler reverse proxies for troubleshooting when you're not a professional client developer. Also, you don't have to muck around with certificates.

The non-SSL interface is not intended for production use, and so doesn't generally support security. However you can configure the server to use OWin-type security. if you do the /metadata endpoint is available to anyone, but to access anything else, clients will have to login using the OWin interface - see below.

Secure Interface

This is an SSL based interface to the server, using OpenSSL. Implementers can use a self-signed certificate, or a certificate signed by a CA. Browsers generally require the latter now

By default, the secure interface allows anyone to retrieve the /metadata endpoint. Any other operations require some form of authentication. The Secure interface supports 3 kinds of security:

  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)
    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens

The interface can support all 3 kinds of security at the same time.

OAuth2 login

This implements the SMART App launch profile, as specified by the HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients can be dynamically registered through the web interface.

Part of the OAuth login process includes identifying the end user. the FHIR Server supports the following methods of identifying a user:

  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)

These methods and the tokens required to administer them are also configured in the authorization file

Security summary:

  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes

OWin Authorization

This is a form of authentication used by the .net OWin framework, though not actually documented as part of the OWin specification (yet?)

User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token. The body contains the parameters username and password, and also grant_type. The server checks the user name and password, and if it is acceptable, returns a JSON body:

{ "access_token" : "[token}", "expires_in" : "{#seconds}", "token_type" : "bearer" }

The client extracts the token, and makes subsequent calls using the header

Authorization: Bearer {token}

Security summary:

  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface

Certificates + JWT

In this method, the client uses an SSL certificate to connect to the server, and the server uses it to identify the client. The server will automatically pick up the client identity from the certificate. In addition, the server can be configured to verify that the certificate is on a known list of acceptable certificates.

The certificates are considered to authenticate the client software. Clients can also provide a JWT in the authorization header as a bearer token:

Authorization: Bearer [JWT]

The server will pick up the JWT and (i nthe future) check that it is valid. If it is, it will treat the JWT as an openID Connect JWT that identifies the user of the software

Administrators can also configure what to do when there is no certificate/JWT, or unrecognised ones:

  • reject the request
  • limit the response (see below)
  • doesn't make any difference

Security summary:

  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface

There aren't any published security advisories

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories


, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Security: HealthIntersections/fhirserver
Security
Report a vulnerability

security.md

FHIRServer Security
This page documents the FHIR Server security.
Principles
The Full FHIRServer offers 2 interfaces: secure, and insecure.
They both have exactly the same functionality, which is
what is described in the FHIR Specification. However,
on the secure interface, clients have to authenticate.
Note that there are 2 different meanings to authenticate:
  • identifying the software that is the client
  • identifying the user that the software is acting on behalf of
Finally, there is authorization - determining what
actions the user authorizes the software to take on their
behalf.
Insecure Interface
This is s a non-SSL interface to the server. it is provided for
user convenience. The main convenience is that it is is easy to
snoop on the traffic, or use simpler reverse proxies for
troubleshooting when you're not a professional client developer.
Also, you don't have to muck around with certificates.
The non-SSL interface is not intended for production use,
and so doesn't generally support security. However you can
configure the server to use OWin-type security. if you do
the /metadata endpoint is available to anyone, but to access
anything else, clients will have to login using the OWin
interface - see below.
Secure Interface
This is an SSL based interface to the server, using OpenSSL.
Implementers can use a self-signed certificate, or a certificate
signed by a CA. Browsers generally require the latter now
By default, the secure interface allows anyone to retrieve
the /metadata endpoint. Any other operations require some form
of authentication. The Secure interface supports 3 kinds of
security:
  • OAuth2 login (actually, the Smart App Launch v1 profile on OAuth2)

    • v2 is planned
  • OWin-type login
  • Certificates + JWT Bearer Tokens
The interface can support all 3 kinds of security at the same
time.
OAuth2 login
This implements the SMART App launch profile, as specified by the
HL7 specification at http://hl7.org/fhir/smart-app-launch. Clients
can be dynamically registered through the web interface.
Part of the OAuth login process includes identifying the
end user. the FHIR Server supports the following methods
of identifying a user:
  • user login maintained in the FHIR Server using the inbuilt SCIM server
  • delegated identify provider to one of Google, Facebook, or HL7.org (other providers can be added)
  • user can authenticate to the system administrator directly (e.g. by skype) (note: no one has ever done this...)
These methods and the tokens required to administer them are
also configured in the authorization file
Security summary:
  • software is identified by the client_id (and possibly secret)
  • user is identified by login or identity provider
  • user authorises software to perform a set of actions using Smart on fhir scopes
OWin Authorization
This is a form of authentication used by the .net OWin framework,
though not actually documented as part of the OWin specification (yet?)
User posts a body of type application/x-www-form-urlencodedto [base]/oauth/token.
The body contains the parameters username and password, and also grant_type.
The server checks the user name and password, and if it is acceptable,
returns a JSON body:
{
"access_token" : "[token}",
"expires_in" : "{#seconds}",
"token_type" : "bearer"
}
The client extracts the token, and makes subsequent calls using
the header
Authorization: Bearer {token}
Security summary:
  • software is identified by the username/password in the call
  • the user is not identified
  • the software is authorised to do anything on the interface
Certificates + JWT
In this method, the client uses an SSL certificate to connect to the server,
and the server uses it to identify the client. The server will automatically
pick up the client identity from the certificate. In addition, the server can
be configured to verify that the certificate is on a known list of acceptable
certificates.
The certificates are considered to authenticate the client software. Clients
can also provide a JWT in the authorization header as a bearer token:
Authorization: Bearer [JWT]
The server will pick up the JWT and (i nthe future) check that it is valid.
If it is, it will treat the JWT as an openID Connect JWT that identifies the
user of the software
Administrators can also configure what to do when there is no certificate/JWT,
or unrecognised ones:
  • reject the request
  • limit the response (see below)
  • doesn't make any difference
Security summary:
  • software is identified by the SSL certificate
  • the user is identified by the JWT
  • the software is authorised to do anything on the interface
 There aren't any published security advisories