Propagate HTTP headers - Coco Pharma example

[MihaiIliescu]

Description

This change represents an example on how HTTP headers can be used for authorisation within a connector. This is a follow up to #6793 and #6851.

Testing

Functional testing

[sonatype-lift]

⚠️ 107 God Classes were detected by Lift in this project. Visit the Lift web console for more details.

[planetf1]

The open metadata security samples project includes 2 connectors currently, both based on coco pharma

• platform
• server

This PR proposes a http security connector, and in that it follows the existing sample.

As such I don't have any issue with merging this in, but it does bring up two questions

a) As the three connectors are seperately identfied/configured, do we want them in seperately deployable jars - this is how we usually do things - which would mean 3 artifacts. However we don't have to do this, ie if closely related
b) more of our samples are moving to repositories outside core egeria, since they are optional. Should we be thinking of that here?

[sonatype-lift]

🛠 Lift Auto-fix

Some of the Lift findings in this PR can be automatically fixed. You can download and apply these changes in your local project directory of your branch to review the suggestions before committing.¹

# Download the patch
curl https://lift.sonatype.com/api/patch/github.com/odpi/egeria/6977.diff -o lift-autofixes.diff

# Apply the patch with git
git apply lift-autofixes.diff

# Review the changes
git diff

Want it all in a single command? Open a terminal in your project's directory and copy and paste the following command:

curl https://lift.sonatype.com/api/patch/github.com/odpi/egeria/6977.diff | git apply

Once you're satisfied commit and push your changes in your project.

Footnotes

1. You can preview the patch by opening the patch URL in the browser. ↩

[lpalashevski]

Approved. See minor comment about adding the example payload in the class javadoc.

[lpalashevski]

The open metadata security samples project includes 2 connectors currently, both based on coco pharma

* platform

* server

This PR proposes a http security connector, and in that it follows the existing sample.

As such I don't have any issue with merging this in, but it does bring up two questions

a) As the three connectors are seperately identfied/configured, do we want them in seperately deployable jars - this is how we usually do things - which would mean 3 artifacts. However we don't have to do this, ie if closely related
b) more of our samples are moving to repositories outside core egeria, since they are optional. Should we be thinking of that here?

@planetf1

I think we should keep the samples under single deployable jar (as is now).

We can move the security connector samples to new repository if we decide in future but at this point it is just extra work and no value (The current samples are static, everything is hard coded. They do not provide value outside of the labs/tutorials)

We should revisit the idea in the next iteration when we introduce connectors that integrate with LDAP and/or provide new services such as token based access control - parts discussed on the last workshop.