[Architecture] WSO2 IS : what are the differences between OpenID Connect & OAuth 2.0 federated authenticators

[Youcef HILEM]

Hi WSO2 IS Team,

Can you please tell me what are the differences between OpenID Connect &
OAuth 2.0 federated authenticators ?

The links for these two authenticators [1]  refer to the same component [2].

We have an OAuth2 server with these endpoints [3]. Can I use this connector
[2] ?

I do not know what to put for the two fields:
- OpenID Connect User ID Location   
- Additional Query Parameters

Also there is no userinfo endpoint. And in this case how to get user
attributes ? Should I use Introspect endpoint ? If so, then I must develop a
specific authenticator for our case.

[1] Federated Authentication -
https://docs.wso2.com/display/IS530/Federated+Authentication
[2] Configuring OAuth2-OpenID Connect -
https://docs.wso2.com/display/IS530/Configuring+OAuth2-OpenID+Connect 
[3] IBM Security Access Manager 9.0.3.1 - OAuth 2.0 endpoints -
https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.3.1/com.ibm.isam.doc/config/concept/OAuthEndpoints.html#oauthendpoints

Thanks
Youcef HILEM



--
Sent from: 
http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architecture-f62919.html
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] - Resource Registration Rest API For API Manager

[Harsha Kumara]

On Fri, Dec 8, 2017 at 11:10 PM, Tharindu Dharmarathna 
wrote:

> Hi Harsha,
>
>
>
> On Fri, Dec 8, 2017 at 10:38 PM, Harsha Kumara  wrote:
>
>> On Tue, Dec 5, 2017 at 12:59 PM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> As per the offline discussion today, we going to implement according to
>>> following way.
>>>
>>> *Rest Apis expose*
>>>
>>> /apis/{apiId}/scopes - POST to Create Scope object.
>>> /apis/{apiid}/scopes - GET Get list of scope names
>>> /apis/{apiid}/scopes/{name} -  GET get the detail of Scope
>>> /apis/{apiid}/scopes/{name} - PUT update the existing scope
>>> /apis/{apiid}/scopes/{name} - Delete delete the scope
>>>
>> What are the restrictions for scope name? Having special charactors will
>> cause issues.
>>
>>>
>>> *Scope assign into the resource.*
>>>
>>> This can be done by following two ways.
>>>
>>> 1.  / apis/{apiid} - PUT scope assign it to resource and those
>>> information stored in swagger.json
>>> 2. /apis/{apiid}/swagger  - PUT swagger.json update with scopes will
>>> create/update accoringly.
>>>
>>> So we are going to store the scopes in the swagger itself and the scope
>> to role mappings in database right?
>>
>
> Scopes are only stored in swagger itself and for the scope to role mapping
> it will resides on the Authorization Server Itself. when we going to show
> the scope, we call the Authorization server endpoint and get the bindings.
>
When it comes to token generation and validation how efficient is to get
scopes information of a resource when we stored scopes in swagger? Does it
has any effect?

>
>>> On Tue, Dec 5, 2017 at 12:39 PM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 @Bhathiya,

 We are not giving sharing the scopes between APIS as those roles can
 have different definitions as below.

 For API1 for resource /menu post need scope1 which have role1 and role2.

 For API2 for resource /abc POST need scope1 which have role3 and role4.

 therefore we can't create scope which can cater above 2.



 On Tue, Dec 5, 2017 at 11:33 AM, Bhathiya Jayasekara >>> > wrote:

> Hi Tharindu,
>
> Have we considered creating scopes in a single place and reusing them
> in multiple APIs (just like we do with endpoints in v3)? I believe it will
> be a useful capability because it allows publishers to reduce the number 
> of
> scopes when there are many APIs and resources.
>
> IINM, in the current implementation, users can't even add the same
> scope even for multiple versions of the same API. Well, that's a separate
> thing to handle anyway.
>
> Thanks,
> Bhathiya
>
> On Tue, Dec 5, 2017 at 1:45 AM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,
>>
>> We are going to develop Resource Registration Rest API for engaging
>> Scope for the resource. I had come up with below flow in order to do the
>> above.
>>
>>
>>
>> In Above Diagram for Store Scopes, we can do below two ways.
>>
>>
>>1. Store under swagger.json as security definition
>>2. Store In database schema.
>>
>> If we are Storing in swagger we have following advantages and
>> disadvantages.
>> *Advantages*
>>
>> 1. The scope can easily manage as we can assign the scopes to a
>> resource inside the swagger.
>>
>> *Disadvantages*.
>>
>> 1. If we have lots of scopes for the API for getting the Details of
>> the scope we have to call the Resource Server Endpoint, therefore it may
>> lead to high network usage.
>> 2. Swagger given by user get changed by injecting our set of
>> properties.
>>
>> I had come up with below set of resources to create scopes and assign
>> scopes
>>
>>
>>1. /apis/{apiid}/scopes - post (add scope for api)
>>2. /apis/{apiid}/scopes - get (get All the scopes for api)
>>3. /apis/{apiid}/scopes/{name} - put update scope
>>4. /apis/{apiid}/scopes/{name} - delete scope
>>5. /apis/{apiid} - put (Apply scopes(add,update,delete) into
>>resources)
>>6. /apis/{apiid} - get (get scopes applied to a resources)
>>
>> Or We can do the below way as Reources are not consider as a sub
>> resources of the API
>>
>>
>>1. /api1/{apiid} - (get,put) These two operations used to add
>>scope,update scope,delete scope,assign scopes to resources.
>>
>>
>> Please let us know your Ideas on this.
>>
>> Thanks
>>
>> *Tharindu Dharmarathna*Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>
>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20

Re: [Architecture] [APIM][C5] - Resource Registration Rest API For API Manager

[Nuwan Dias]

On Mon, Dec 11, 2017 at 4:31 AM, Harsha Kumara  wrote:

>
>
> On Fri, Dec 8, 2017 at 11:10 PM, Tharindu Dharmarathna  > wrote:
>
>> Hi Harsha,
>>
>>
>>
>> On Fri, Dec 8, 2017 at 10:38 PM, Harsha Kumara  wrote:
>>
>>> On Tue, Dec 5, 2017 at 12:59 PM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi All,

 As per the offline discussion today, we going to implement according to
 following way.

 *Rest Apis expose*

 /apis/{apiId}/scopes - POST to Create Scope object.
 /apis/{apiid}/scopes - GET Get list of scope names
 /apis/{apiid}/scopes/{name} -  GET get the detail of Scope
 /apis/{apiid}/scopes/{name} - PUT update the existing scope
 /apis/{apiid}/scopes/{name} - Delete delete the scope

>>> What are the restrictions for scope name? Having special charactors will
>>> cause issues.
>>>

 *Scope assign into the resource.*

 This can be done by following two ways.

 1.  / apis/{apiid} - PUT scope assign it to resource and those
 information stored in swagger.json
 2. /apis/{apiid}/swagger  - PUT swagger.json update with scopes will
 create/update accoringly.

 So we are going to store the scopes in the swagger itself and the scope
>>> to role mappings in database right?
>>>
>>
>> Scopes are only stored in swagger itself and for the scope to role
>> mapping it will resides on the Authorization Server Itself. when we going
>> to show the scope, we call the Authorization server endpoint and get the
>> bindings.
>>
> When it comes to token generation and validation how efficient is to get
> scopes information of a resource when we stored scopes in swagger? Does it
> has any effect?
>

Since Ballerina is tightly linked to Swagger we could probably get the
scopes from the Swagger file to the Ballerina service itself, at the point
of deploying the API. If the scopes are in the Ballerina resource itself we
won't have to read the swagger for scopes.

>
 On Tue, Dec 5, 2017 at 12:39 PM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> @Bhathiya,
>
> We are not giving sharing the scopes between APIS as those roles can
> have different definitions as below.
>
> For API1 for resource /menu post need scope1 which have role1 and
> role2.
>
> For API2 for resource /abc POST need scope1 which have role3 and
> role4.
>
> therefore we can't create scope which can cater above 2.
>
>
>
> On Tue, Dec 5, 2017 at 11:33 AM, Bhathiya Jayasekara <
> bhath...@wso2.com> wrote:
>
>> Hi Tharindu,
>>
>> Have we considered creating scopes in a single place and reusing them
>> in multiple APIs (just like we do with endpoints in v3)? I believe it 
>> will
>> be a useful capability because it allows publishers to reduce the number 
>> of
>> scopes when there are many APIs and resources.
>>
>> IINM, in the current implementation, users can't even add the same
>> scope even for multiple versions of the same API. Well, that's a separate
>> thing to handle anyway.
>>
>> Thanks,
>> Bhathiya
>>
>> On Tue, Dec 5, 2017 at 1:45 AM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> We are going to develop Resource Registration Rest API for engaging
>>> Scope for the resource. I had come up with below flow in order to do the
>>> above.
>>>
>>>
>>>
>>> In Above Diagram for Store Scopes, we can do below two ways.
>>>
>>>
>>>1. Store under swagger.json as security definition
>>>2. Store In database schema.
>>>
>>> If we are Storing in swagger we have following advantages and
>>> disadvantages.
>>> *Advantages*
>>>
>>> 1. The scope can easily manage as we can assign the scopes to a
>>> resource inside the swagger.
>>>
>>> *Disadvantages*.
>>>
>>> 1. If we have lots of scopes for the API for getting the Details of
>>> the scope we have to call the Resource Server Endpoint, therefore it may
>>> lead to high network usage.
>>> 2. Swagger given by user get changed by injecting our set of
>>> properties.
>>>
>>> I had come up with below set of resources to create scopes and
>>> assign scopes
>>>
>>>
>>>1. /apis/{apiid}/scopes - post (add scope for api)
>>>2. /apis/{apiid}/scopes - get (get All the scopes for api)
>>>3. /apis/{apiid}/scopes/{name} - put update scope
>>>4. /apis/{apiid}/scopes/{name} - delete scope
>>>5. /apis/{apiid} - put (Apply scopes(add,update,delete) into
>>>resources)
>>>6. /apis/{apiid} - get (get scopes applied to a resources)
>>>
>>> Or We can do the below way as Reources are not consider as a sub
>>> resources of the API
>>>
>>>
>>>1. /api1/{apiid} - (get,put) These two operations used to add
>>>scope,update scop

Re: [Architecture] [APIM][C5] - Resource Registration Rest API For API Manager

[roshan wijesena]

Nuwan, When we export the  swagger file, we should be able to get all the
scopes that are bonded to the Ballerina resource right?

On Mon, Dec 11, 2017 at 2:44 PM, Nuwan Dias  wrote:

>
>
> On Mon, Dec 11, 2017 at 4:31 AM, Harsha Kumara  wrote:
>
>>
>>
>> On Fri, Dec 8, 2017 at 11:10 PM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi Harsha,
>>>
>>>
>>>
>>> On Fri, Dec 8, 2017 at 10:38 PM, Harsha Kumara  wrote:
>>>
 On Tue, Dec 5, 2017 at 12:59 PM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> Hi All,
>
> As per the offline discussion today, we going to implement
> according to following way.
>
> *Rest Apis expose*
>
> /apis/{apiId}/scopes - POST to Create Scope object.
> /apis/{apiid}/scopes - GET Get list of scope names
> /apis/{apiid}/scopes/{name} -  GET get the detail of Scope
> /apis/{apiid}/scopes/{name} - PUT update the existing scope
> /apis/{apiid}/scopes/{name} - Delete delete the scope
>
 What are the restrictions for scope name? Having special charactors
 will cause issues.

>
> *Scope assign into the resource.*
>
> This can be done by following two ways.
>
> 1.  / apis/{apiid} - PUT scope assign it to resource and those
> information stored in swagger.json
> 2. /apis/{apiid}/swagger  - PUT swagger.json update with scopes will
> create/update accoringly.
>
> So we are going to store the scopes in the swagger itself and the
 scope to role mappings in database right?

>>>
>>> Scopes are only stored in swagger itself and for the scope to role
>>> mapping it will resides on the Authorization Server Itself. when we going
>>> to show the scope, we call the Authorization server endpoint and get the
>>> bindings.
>>>
>> When it comes to token generation and validation how efficient is to get
>> scopes information of a resource when we stored scopes in swagger? Does it
>> has any effect?
>>
>
> Since Ballerina is tightly linked to Swagger we could probably get the
> scopes from the Swagger file to the Ballerina service itself, at the point
> of deploying the API. If the scopes are in the Ballerina resource itself we
> won't have to read the swagger for scopes.
>
>>
> On Tue, Dec 5, 2017 at 12:39 PM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> @Bhathiya,
>>
>> We are not giving sharing the scopes between APIS as those roles can
>> have different definitions as below.
>>
>> For API1 for resource /menu post need scope1 which have role1 and
>> role2.
>>
>> For API2 for resource /abc POST need scope1 which have role3 and
>> role4.
>>
>> therefore we can't create scope which can cater above 2.
>>
>>
>>
>> On Tue, Dec 5, 2017 at 11:33 AM, Bhathiya Jayasekara <
>> bhath...@wso2.com> wrote:
>>
>>> Hi Tharindu,
>>>
>>> Have we considered creating scopes in a single place and reusing
>>> them in multiple APIs (just like we do with endpoints in v3)? I believe
>>> it will be a useful capability because it allows publishers to reduce 
>>> the
>>> number of scopes when there are many APIs and resources.
>>>
>>> IINM, in the current implementation, users can't even add the same
>>> scope even for multiple versions of the same API. Well, that's a 
>>> separate
>>> thing to handle anyway.
>>>
>>> Thanks,
>>> Bhathiya
>>>
>>> On Tue, Dec 5, 2017 at 1:45 AM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi All,

 We are going to develop Resource Registration Rest API for engaging
 Scope for the resource. I had come up with below flow in order to do 
 the
 above.



 In Above Diagram for Store Scopes, we can do below two ways.


1. Store under swagger.json as security definition
2. Store In database schema.

 If we are Storing in swagger we have following advantages and
 disadvantages.
 *Advantages*

 1. The scope can easily manage as we can assign the scopes to a
 resource inside the swagger.

 *Disadvantages*.

 1. If we have lots of scopes for the API for getting the Details of
 the scope we have to call the Resource Server Endpoint, therefore it 
 may
 lead to high network usage.
 2. Swagger given by user get changed by injecting our set of
 properties.

 I had come up with below set of resources to create scopes and
 assign scopes


1. /apis/{apiid}/scopes - post (add scope for api)
2. /apis/{apiid}/scopes - get (get All the scopes for api)
3. /apis/{apiid}/scopes/{name} - put update scope
4. /apis/{apiid}/scopes/{name} - delete scope
5. /ap

Re: [Architecture] [APIM][C5] - Resource Registration Rest API For API Manager

[Nuwan Dias]

On Mon, Dec 11, 2017 at 4:50 AM, roshan wijesena 
wrote:

> Nuwan, When we export the  swagger file, we should be able to get all the
> scopes that are bonded to the Ballerina resource right?
>

Scopes are primarily declared on the Swagger file itself. So if you export
the Swagger file, you can get all the scopes from there. Swagger to
Ballerina is a one-to-one mapping. So a scope declared under a resource in
the Swagger is exactly the same scope attached to the resource in the
Ballerina service.

>
> On Mon, Dec 11, 2017 at 2:44 PM, Nuwan Dias  wrote:
>
>>
>>
>> On Mon, Dec 11, 2017 at 4:31 AM, Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Fri, Dec 8, 2017 at 11:10 PM, Tharindu Dharmarathna <
>>> tharin...@wso2.com> wrote:
>>>
 Hi Harsha,



 On Fri, Dec 8, 2017 at 10:38 PM, Harsha Kumara 
 wrote:

> On Tue, Dec 5, 2017 at 12:59 PM, Tharindu Dharmarathna <
> tharin...@wso2.com> wrote:
>
>> Hi All,
>>
>> As per the offline discussion today, we going to implement
>> according to following way.
>>
>> *Rest Apis expose*
>>
>> /apis/{apiId}/scopes - POST to Create Scope object.
>> /apis/{apiid}/scopes - GET Get list of scope names
>> /apis/{apiid}/scopes/{name} -  GET get the detail of Scope
>> /apis/{apiid}/scopes/{name} - PUT update the existing scope
>> /apis/{apiid}/scopes/{name} - Delete delete the scope
>>
> What are the restrictions for scope name? Having special charactors
> will cause issues.
>
>>
>> *Scope assign into the resource.*
>>
>> This can be done by following two ways.
>>
>> 1.  / apis/{apiid} - PUT scope assign it to resource and those
>> information stored in swagger.json
>> 2. /apis/{apiid}/swagger  - PUT swagger.json update with scopes will
>> create/update accoringly.
>>
>> So we are going to store the scopes in the swagger itself and the
> scope to role mappings in database right?
>

 Scopes are only stored in swagger itself and for the scope to role
 mapping it will resides on the Authorization Server Itself. when we going
 to show the scope, we call the Authorization server endpoint and get the
 bindings.

>>> When it comes to token generation and validation how efficient is to get
>>> scopes information of a resource when we stored scopes in swagger? Does it
>>> has any effect?
>>>
>>
>> Since Ballerina is tightly linked to Swagger we could probably get the
>> scopes from the Swagger file to the Ballerina service itself, at the point
>> of deploying the API. If the scopes are in the Ballerina resource itself we
>> won't have to read the swagger for scopes.
>>
>>>
>> On Tue, Dec 5, 2017 at 12:39 PM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> @Bhathiya,
>>>
>>> We are not giving sharing the scopes between APIS as those roles can
>>> have different definitions as below.
>>>
>>> For API1 for resource /menu post need scope1 which have role1 and
>>> role2.
>>>
>>> For API2 for resource /abc POST need scope1 which have role3 and
>>> role4.
>>>
>>> therefore we can't create scope which can cater above 2.
>>>
>>>
>>>
>>> On Tue, Dec 5, 2017 at 11:33 AM, Bhathiya Jayasekara <
>>> bhath...@wso2.com> wrote:
>>>
 Hi Tharindu,

 Have we considered creating scopes in a single place and reusing
 them in multiple APIs (just like we do with endpoints in v3)? I believe
 it will be a useful capability because it allows publishers to reduce 
 the
 number of scopes when there are many APIs and resources.

 IINM, in the current implementation, users can't even add the same
 scope even for multiple versions of the same API. Well, that's a 
 separate
 thing to handle anyway.

 Thanks,
 Bhathiya

 On Tue, Dec 5, 2017 at 1:45 AM, Tharindu Dharmarathna <
 tharin...@wso2.com> wrote:

> Hi All,
>
> We are going to develop Resource Registration Rest API for
> engaging Scope for the resource. I had come up with below flow in 
> order to
> do the above.
>
>
>
> In Above Diagram for Store Scopes, we can do below two ways.
>
>
>1. Store under swagger.json as security definition
>2. Store In database schema.
>
> If we are Storing in swagger we have following advantages and
> disadvantages.
> *Advantages*
>
> 1. The scope can easily manage as we can assign the scopes to a
> resource inside the swagger.
>
> *Disadvantages*.
>
> 1. If we have lots of scopes for the API for getting the Details
> of the scope we have to call the Resource Server Endpoint, therefore 
> it may
>

Re: [Architecture] WSO2 IS : what are the differences between OpenID Connect & OAuth 2.0 federated authenticators

[Hasanthi Purnima Dissanayake]

Hi Youcef,

>
> Can you please tell me what are the differences between OpenID Connect &
> OAuth 2.0 federated authenticators ?
>
> The links for these two authenticators [1]  refer to the same component
> [2].


Actually OAuth 2.0 is an authorization framework that is capable of
providing a way for clients to access a resource with restricted access on
behalf of the resource owner while OIDC facilitates clients to verify the
end-user identity against the authentication performed by an authorization
server. At the same time, OIDC provides methods to transfer the end user
information through claims.OIDC protocol is built on top of the OAuth2
protocol.

We have an OAuth2 server with these endpoints [3]. Can I use this connector
> [2] ?
>
> I do not know what to put for the two fields:
> - OpenID Connect User ID Location
> - Additional Query Parameters


As you are using a oauth server, you can keep the second field empty and
keep the default setting for the 'OpenID Connect User ID Location'

Also there is no userinfo endpoint. And in this case how to get user
> attributes ?

As I mentioned above we need to use openid protocol to get end user
attributes as the purpose of oauth is to provide accessibility for a
resource with restricted access.

Should I use Introspect endpoint ?
>
OAuth 2.0 Token Introspection defines a protocol that allows authorized
protected resources to query the authorization server to determine the set
of metadata for a given token that was presented to them by an OAuth
Client.  So the response will contain few claims as user name, but from
this endpoint there is no way to get the whole set of user claims. So our
recommendation here is to use a OIDC server in order to obtain the user
claims.

Thanks,


On Mon, Dec 11, 2017 at 12:46 AM, Youcef HILEM 
wrote:

> Hi WSO2 IS Team,
>
> Can you please tell me what are the differences between OpenID Connect &
> OAuth 2.0 federated authenticators ?
>
> The links for these two authenticators [1]  refer to the same component
> [2].
>
> We have an OAuth2 server with these endpoints [3]. Can I use this connector
> [2] ?
>
> I do not know what to put for the two fields:
> - OpenID Connect User ID Location
> - Additional Query Parameters
>
> Also there is no userinfo endpoint. And in this case how to get user
> attributes ? Should I use Introspect endpoint ? If so, then I must develop
> a
> specific authenticator for our case.
>
> [1] Federated Authentication -
> https://docs.wso2.com/display/IS530/Federated+Authentication
> [2] Configuring OAuth2-OpenID Connect -
> https://docs.wso2.com/display/IS530/Configuring+OAuth2-OpenID+Connect
> [3] IBM Security Access Manager 9.0.3.1 - OAuth 2.0 endpoints -
> https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.
> 3.1/com.ibm.isam.doc/config/concept/OAuthEndpoints.html#oauthendpoints
>
> Thanks
> Youcef HILEM
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Architecture-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 

Hasanthi Dissanayake

Senior Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture