Yes OAuth2, maybe we can leverage that infrastructure for regular WS
interaction as well.
On 6/9/13 10:44 AM, Alex O'Ree wrote:
I'm assuming you mean OAuth2? http://oauth.net/2/ or http://www.auth2.com/
I agree on the query parameter, request URLs are routinely logged by
application servers. HTTP Header is the way to go, along with some
kind of expiration mechanism.
On Sun, Jun 9, 2013 at 10:38 AM, Kurt T Stam <[email protected]> wrote:
On 6/9/13 10:34 AM, Alex O'Ree wrote:
I'm writing a REST style wrapper for the inquiry api and started
thinking about how to support authenticated users to the REST inquiry
binding. I came up with two options
1) Use servlet container authentication, then just trust the container
provided identity. We'll need a way to provide that info to the
existing service code
2) Create a REST endpoint for the Security API that uses post, then
pass the auth token as a query parameter or something to the REST
bindings
Any one else have any ideas or comments?
How about using an AUTH2 approach, and the AUTH2 token is the UDDI token?
I think this might align pretty nicely? This way 3rd party apps can embed
UDDI interaction
participating in the same security context? It's a bit like option 2. I
think in AUTH2
you pass the auth token in the header. I think it's risky to put it as an
argument anyway.