Mapping the Security API to REST style endpoints

[Alex O'Ree <sp...@gmail.com>]

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?

Re: Mapping the Security API to REST style endpoints

[Kurt T Stam <ku...@gmail.com>]

That's nice that CXF supports it. Since this is an add on feature I'm 
fine with it being
restricted to CXF. I'm guessing that CXF will be used in 80% of our 
deployments anyway.
We can document what features someone would need to implement to port it 
when using other stacks.

On 6/9/13 12:08 PM, Alex O'Ree wrote:
> It looks like CXF supports it. By going this route, we may have to
> restrict the availability of the REST endpoints to deployments with
> CXF as the WS stack.
>
> On Sun, Jun 9, 2013 at 10:51 AM, Kurt T Stam <ku...@gmail.com> wrote:
>> 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 <ku...@gmail.com> 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.
>>>>

Re: Mapping the Security API to REST style endpoints

[Alex O'Ree <sp...@gmail.com>]

It looks like CXF supports it. By going this route, we may have to
restrict the availability of the REST endpoints to deployments with
CXF as the WS stack.

On Sun, Jun 9, 2013 at 10:51 AM, Kurt T Stam <ku...@gmail.com> wrote:
> 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 <ku...@gmail.com> 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.
>>>
>

Re: Mapping the Security API to REST style endpoints

[Kurt T Stam <ku...@gmail.com>]

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 <ku...@gmail.com> 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.
>>

Re: Mapping the Security API to REST style endpoints

[Alex O'Ree <sp...@gmail.com>]

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 <ku...@gmail.com> 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.
>

Re: Mapping the Security API to REST style endpoints

[Kurt T Stam <ku...@gmail.com>]

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.