Hi all,
I am looking for some advice regarding implementing oauth2 for the http
component when authentication with Microsoft authentication servers. Many of
our authorisations go through this so I'd prefer a more reusable solution.
First up, you might ask why can't I just use the oauth2 parameters provided by
the http component?
Because Microsoft servers expect a token request in the following format.
POST /{tenant}/oauth2/v2.0/token HTTP/1.1 //Line breaks for clarity
Host: login.microsoftonline.com:443
Content-Type: application/x-www-form-urlencoded
client_id=<client id>
&scope=<some scope>
&client_secret=<client secret>
&grant_type=client_credentials
While camel builds a token request in the following format.
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic <base 64 encoded "client id:client secret">
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
scope=<some scope>
Now, you could argue Microsoft isn't meeting the standard (rfc6749) or that
camel is being too strict on the standard(In my reading, I doesn't seem to
precisely specify how to pass in the clientid and secret, or even that you need
clientid and secret to conform to the standard. The only place it mentions the
Authorization header is in an example, and an example to me means one possible
way of implementing the standard - not the only way).
Regardless, I'd like some suggests around the best way to implement this.
Some possibilities...
1. Set some known variables for clientid, secret etc etc, and use enrich()
to make my own call to the authentication server
2. Implement my own HttpClientConfigurer extending OAuth2ClientConfigurer.
* This isn't quite so straightforward as I'd like because I can't extend
the existing OAuth2ClientConfigurer. It is created a runtime, rather than route
configuration. It takes clientid etc in the constructor, which are only
available at runtime, not the normal place where you would configure a custom
HttpClientConfigurer. In other words - Unlike other HttpClientConfigurer, the
OAuth2ClientConfigurer is one object per http call, rather then one globally
reused object. To inject an extension of OAuth2ClientConfigurer, that works in
the same way, I'd need to create a new HttpComponent implementation(also
difficult to extend the existing implementation due to private methods.)
3. Implement my own HttpClientConfigurer that doesn' t extending
OAuth2ClientConfigurer - and implement my own custom oauth2 parameters that
don't cross over with the standard ones in order to avoid invoking the
out-of-the-box OAuth2ClientConfigurer.
4. Contribute an extendable OAuth2ClientConfigurer, which would possible
need some degree of redesign of this portion of the HttpComponent.
Or any other recommendations.
I guess, I'm leaning towards the enrich - as the quickest way to implement - it
just hurts to not use the oauth2 features that come out-of-the-box.
Thanks in advance.
Andy
[cid:guild_group_box_1d412af1-affb-4c07-9f3a-296134fb000c.png]<https://www.guildgroup.com.au/><https://www.guildgroup.com.au/>
Andy Gilette
Solutions Architect - Software Engineer
Level 1, 132 Leichhardt Street, Spring Hill, QLD 4000
p: +61 3 7000 0405
w: guildgroup.com.au<https://www.guildgroup.com.au>
[cid:thrivetogether-blue_4c72fa74-1bd9-4732-bb06-cf4ebbd58bac.png]
We work flexibly at Guild. I'm sending this message at a time that suits me.
Please feel comfortable knowing that I don't expect you to read, respond to or
action it outside of regular working hours.
In the spirit of reconciliation, Guild Group acknowledges the Traditional
Custodians of Country throughout Australia and their connections to land, sea,
and community. We pay our respect to their Elders past and present and extend
that respect to all Aboriginal and Torres Strait Islander peoples today.
________________________________
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail from your system. Any
unauthorised copying, disclosure, dissemination or distribution of the material
in this e-mail is strictly forbidden. The sender, as well as Guild Group
Holdings and any of its related companies do not guarantee the integrity of any
e-mails or attached files. E-mail transmission cannot be guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any such problems in the contents of this message
which arise as a result of e-mail transmissions.
