Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Asela Pathberiya]

On Wed, Apr 5, 2017 at 9:04 AM, Harsha Thirimanna  wrote:

>
>
> On Apr 1, 2017 10:37 PM, "Farasath Ahamed"  wrote:
>
>
>
>
>
> On Sat, Apr 1, 2017 at 11:27 AM, Bhathiya Jayasekara 
> wrote:
>
>>
>>
>> On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed 
>> wrote:
>>
>>>
>>>
>>> On Thursday, March 30, 2017, Sajith Kariyawasam  wrote:
>>>

 When discussing about possible ways of implementing SSO for API Manager
 3.0 (C5) we came up with following two approaches,
 In API Manager 3.0, store, publisher and admin apps will be Oauth
 clients, which works with access tokens.

 1. Access token retrieved via SAML grant

 - When a user requests a resource, SAML client in the backend will
 create a SAML request and forwards to IDP
 - Once the user logged in to IDP,  SAML response will be sent back to
 the client.
 - SAML response will be then validated and if successful user will be
 logged into the app.
 - Exchange the SAML token to an access token


 ​

 2. Access token retrieved via Authorization code grant

 When a user requests a resource, if he is not authenticated he will be
 redirected to the Authorization server.
 Then user provides username / pwd there and will get an authorization
 code.
 Then that authorization code is used to obtain the access token and use
 that access token in subsequent calls.


 Therefore it seems that, there is no real need of using SAML here,
 and implementation wise its much simpler to use 2nd approach as there
 won't be any dependencies for SAML libraries like we had in C4.

 Appreciate your thoughts in this

>>>
>>>
>>> I am bit confused by this diagram :)
>>>
>>
>> That's fair, because this diagram is drawn not to explain all the steps
>> in OAuth2 flow, but to show that the SAML and OAuth2 flows are similar.
>>
>>
>>>
>>> If I understood correctly, in OIDC flow diagram above the Resource
>>> Server(or rather the OAuth client) would be either Publisher, Store or
>>> Admin portal and the client is something like an agent like browser.
>>>
>>> Based on the usual OIDC flow,
>>> Then in step B, the user will be directed to IDP and upon authentication
>>> will get the authorization code(not an access token?) in step D.
>>>
>>
>> Actually all these happen in step A. Within step A, there is a call to to
>> IDP, which authenticates and fetches the auth code. Then in step B, it is
>> sent to the browser via a redirect.
>>
>> However, it doesn't look like the article in the image reference
>> discusses about OIDC. Looks like the article is about just OAuth2. (Correct
>> me if I'm missing anything here)
>>
>> Anyway, I'm +1 to have OIDC here.
>>
>
> Yeah I think it should be OIDC in any case, otherwise we can't get user
> attributes from an access token introspection call (Unless the
> Authorization Server sends custom claims) in Step E if we go by the OAuth2
> flow.
>
>
>
> Yes +1 to use second approach and it must be OIDC here.
>


Does it mean that we are removing the SAML2 SSO support from
store/publisher ?   if it is;  What is the reason for it ?

We need to support for both  SAML2 SSO & ODIC.

Thanks,
Asela.


>
>
>>
>> Thanks,
>> Bhathiya
>>
>>
>>>
>>> Thereafter the resource server usually does a backend call to get the
>>> actual id_token that contain user attributes plus an access token too.
>>>
>>> Step E would be the call to userinfo endpoint with the access token get
>>> the user attributes.
>>>
>>> In the above diagram in step B the client(browser agent) receives an
>>> authorization code. Can you please explain how this happens?
>>>
>>>
>>>
 ​
 Image reference : https://www.mutuallyhuman.co
 m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/


 Thanks,
 Sajith

 --
 Sajith Kariyawasam
 *Associate Tech Lead*
 *WSO2 Inc.; http://wso2.com *
 *Committer and PMC member, Apache Stratos *
 *AMIE (SL)*
 *Mobile: 0772269575 <077%20226%209575>*

>>>
>>>
>>> --
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com *
>>
>> *Phone: +94715478185 <+94%2071%20547%208185>*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> *
>> *Twitter: https://twitter.com/bhathiyax *
>> *Blog: http://movingaheadblog.blogspot.com
>> 

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Harsha Thirimanna]

On Apr 1, 2017 10:37 PM, "Farasath Ahamed"  wrote:





On Sat, Apr 1, 2017 at 11:27 AM, Bhathiya Jayasekara 
wrote:

>
>
> On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Thursday, March 30, 2017, Sajith Kariyawasam  wrote:
>>
>>>
>>> When discussing about possible ways of implementing SSO for API Manager
>>> 3.0 (C5) we came up with following two approaches,
>>> In API Manager 3.0, store, publisher and admin apps will be Oauth
>>> clients, which works with access tokens.
>>>
>>> 1. Access token retrieved via SAML grant
>>>
>>> - When a user requests a resource, SAML client in the backend will
>>> create a SAML request and forwards to IDP
>>> - Once the user logged in to IDP,  SAML response will be sent back to
>>> the client.
>>> - SAML response will be then validated and if successful user will be
>>> logged into the app.
>>> - Exchange the SAML token to an access token
>>>
>>>
>>> ​
>>>
>>> 2. Access token retrieved via Authorization code grant
>>>
>>> When a user requests a resource, if he is not authenticated he will be
>>> redirected to the Authorization server.
>>> Then user provides username / pwd there and will get an authorization
>>> code.
>>> Then that authorization code is used to obtain the access token and use
>>> that access token in subsequent calls.
>>>
>>>
>>> Therefore it seems that, there is no real need of using SAML here,
>>> and implementation wise its much simpler to use 2nd approach as there
>>> won't be any dependencies for SAML libraries like we had in C4.
>>>
>>> Appreciate your thoughts in this
>>>
>>
>>
>> I am bit confused by this diagram :)
>>
>
> That's fair, because this diagram is drawn not to explain all the steps in
> OAuth2 flow, but to show that the SAML and OAuth2 flows are similar.
>
>
>>
>> If I understood correctly, in OIDC flow diagram above the Resource
>> Server(or rather the OAuth client) would be either Publisher, Store or
>> Admin portal and the client is something like an agent like browser.
>>
>> Based on the usual OIDC flow,
>> Then in step B, the user will be directed to IDP and upon authentication
>> will get the authorization code(not an access token?) in step D.
>>
>
> Actually all these happen in step A. Within step A, there is a call to to
> IDP, which authenticates and fetches the auth code. Then in step B, it is
> sent to the browser via a redirect.
>
> However, it doesn't look like the article in the image reference discusses
> about OIDC. Looks like the article is about just OAuth2. (Correct me if I'm
> missing anything here)
>
> Anyway, I'm +1 to have OIDC here.
>

Yeah I think it should be OIDC in any case, otherwise we can't get user
attributes from an access token introspection call (Unless the
Authorization Server sends custom claims) in Step E if we go by the OAuth2
flow.



Yes +1 to use second approach and it must be OIDC here.



>
> Thanks,
> Bhathiya
>
>
>>
>> Thereafter the resource server usually does a backend call to get the
>> actual id_token that contain user attributes plus an access token too.
>>
>> Step E would be the call to userinfo endpoint with the access token get
>> the user attributes.
>>
>> In the above diagram in step B the client(browser agent) receives an
>> authorization code. Can you please explain how this happens?
>>
>>
>>
>>> ​
>>> Image reference : https://www.mutuallyhuman.co
>>> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>>>
>>>
>>> Thanks,
>>> Sajith
>>>
>>> --
>>> Sajith Kariyawasam
>>> *Associate Tech Lead*
>>> *WSO2 Inc.; http://wso2.com *
>>> *Committer and PMC member, Apache Stratos *
>>> *AMIE (SL)*
>>> *Mobile: 0772269575 <077%20226%209575>*
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
___
Architecture mailing list

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Farasath Ahamed]

On Sat, Apr 1, 2017 at 11:27 AM, Bhathiya Jayasekara 
wrote:

>
>
> On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed 
> wrote:
>
>>
>>
>> On Thursday, March 30, 2017, Sajith Kariyawasam  wrote:
>>
>>>
>>> When discussing about possible ways of implementing SSO for API Manager
>>> 3.0 (C5) we came up with following two approaches,
>>> In API Manager 3.0, store, publisher and admin apps will be Oauth
>>> clients, which works with access tokens.
>>>
>>> 1. Access token retrieved via SAML grant
>>>
>>> - When a user requests a resource, SAML client in the backend will
>>> create a SAML request and forwards to IDP
>>> - Once the user logged in to IDP,  SAML response will be sent back to
>>> the client.
>>> - SAML response will be then validated and if successful user will be
>>> logged into the app.
>>> - Exchange the SAML token to an access token
>>>
>>>
>>> ​
>>>
>>> 2. Access token retrieved via Authorization code grant
>>>
>>> When a user requests a resource, if he is not authenticated he will be
>>> redirected to the Authorization server.
>>> Then user provides username / pwd there and will get an authorization
>>> code.
>>> Then that authorization code is used to obtain the access token and use
>>> that access token in subsequent calls.
>>>
>>>
>>> Therefore it seems that, there is no real need of using SAML here,
>>> and implementation wise its much simpler to use 2nd approach as there
>>> won't be any dependencies for SAML libraries like we had in C4.
>>>
>>> Appreciate your thoughts in this
>>>
>>
>>
>> I am bit confused by this diagram :)
>>
>
> That's fair, because this diagram is drawn not to explain all the steps in
> OAuth2 flow, but to show that the SAML and OAuth2 flows are similar.
>
>
>>
>> If I understood correctly, in OIDC flow diagram above the Resource
>> Server(or rather the OAuth client) would be either Publisher, Store or
>> Admin portal and the client is something like an agent like browser.
>>
>> Based on the usual OIDC flow,
>> Then in step B, the user will be directed to IDP and upon authentication
>> will get the authorization code(not an access token?) in step D.
>>
>
> Actually all these happen in step A. Within step A, there is a call to to
> IDP, which authenticates and fetches the auth code. Then in step B, it is
> sent to the browser via a redirect.
>
> However, it doesn't look like the article in the image reference discusses
> about OIDC. Looks like the article is about just OAuth2. (Correct me if I'm
> missing anything here)
>
> Anyway, I'm +1 to have OIDC here.
>

Yeah I think it should be OIDC in any case, otherwise we can't get user
attributes from an access token introspection call (Unless the
Authorization Server sends custom claims) in Step E if we go by the OAuth2
flow.


>
> Thanks,
> Bhathiya
>
>
>>
>> Thereafter the resource server usually does a backend call to get the
>> actual id_token that contain user attributes plus an access token too.
>>
>> Step E would be the call to userinfo endpoint with the access token get
>> the user attributes.
>>
>> In the above diagram in step B the client(browser agent) receives an
>> authorization code. Can you please explain how this happens?
>>
>>
>>
>>> ​
>>> Image reference : https://www.mutuallyhuman.co
>>> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>>>
>>>
>>> Thanks,
>>> Sajith
>>>
>>> --
>>> Sajith Kariyawasam
>>> *Associate Tech Lead*
>>> *WSO2 Inc.; http://wso2.com *
>>> *Committer and PMC member, Apache Stratos *
>>> *AMIE (SL)*
>>> *Mobile: 0772269575 <077%20226%209575>*
>>>
>>
>>
>> --
>> Farasath Ahamed
>> Software Engineer, WSO2 Inc.; http://wso2.com
>> Mobile: +94777603866
>> Blog: blog.farazath.com
>> Twitter: @farazath619 
>> 
>>
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Bhathiya Jayasekara]

On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed  wrote:

>
>
> On Thursday, March 30, 2017, Sajith Kariyawasam  wrote:
>
>>
>> When discussing about possible ways of implementing SSO for API Manager
>> 3.0 (C5) we came up with following two approaches,
>> In API Manager 3.0, store, publisher and admin apps will be Oauth
>> clients, which works with access tokens.
>>
>> 1. Access token retrieved via SAML grant
>>
>> - When a user requests a resource, SAML client in the backend will create
>> a SAML request and forwards to IDP
>> - Once the user logged in to IDP,  SAML response will be sent back to the
>> client.
>> - SAML response will be then validated and if successful user will be
>> logged into the app.
>> - Exchange the SAML token to an access token
>>
>>
>> ​
>>
>> 2. Access token retrieved via Authorization code grant
>>
>> When a user requests a resource, if he is not authenticated he will be
>> redirected to the Authorization server.
>> Then user provides username / pwd there and will get an authorization
>> code.
>> Then that authorization code is used to obtain the access token and use
>> that access token in subsequent calls.
>>
>>
>> Therefore it seems that, there is no real need of using SAML here,
>> and implementation wise its much simpler to use 2nd approach as there
>> won't be any dependencies for SAML libraries like we had in C4.
>>
>> Appreciate your thoughts in this
>>
>
>
> I am bit confused by this diagram :)
>

That's fair, because this diagram is drawn not to explain all the steps in
OAuth2 flow, but to show that the SAML and OAuth2 flows are similar.


>
> If I understood correctly, in OIDC flow diagram above the Resource
> Server(or rather the OAuth client) would be either Publisher, Store or
> Admin portal and the client is something like an agent like browser.
>
> Based on the usual OIDC flow,
> Then in step B, the user will be directed to IDP and upon authentication
> will get the authorization code(not an access token?) in step D.
>

Actually all these happen in step A. Within step A, there is a call to to
IDP, which authenticates and fetches the auth code. Then in step B, it is
sent to the browser via a redirect.

However, it doesn't look like the article in the image reference discusses
about OIDC. Looks like the article is about just OAuth2. (Correct me if I'm
missing anything here)

Anyway, I'm +1 to have OIDC here.

Thanks,
Bhathiya


>
> Thereafter the resource server usually does a backend call to get the
> actual id_token that contain user attributes plus an access token too.
>
> Step E would be the call to userinfo endpoint with the access token get
> the user attributes.
>
> In the above diagram in step B the client(browser agent) receives an
> authorization code. Can you please explain how this happens?
>
>
>
>> ​
>> Image reference : https://www.mutuallyhuman.co
>> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>>
>>
>> Thanks,
>> Sajith
>>
>> --
>> Sajith Kariyawasam
>> *Associate Tech Lead*
>> *WSO2 Inc.; http://wso2.com *
>> *Committer and PMC member, Apache Stratos *
>> *AMIE (SL)*
>> *Mobile: 0772269575 <077%20226%209575>*
>>
>
>
> --
> Farasath Ahamed
> Software Engineer, WSO2 Inc.; http://wso2.com
> Mobile: +94777603866
> Blog: blog.farazath.com
> Twitter: @farazath619 
> 
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Bhathiya Jayasekara*
*Associate Technical Lead,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Farasath Ahamed]

On Thursday, March 30, 2017, Sajith Kariyawasam  wrote:

>
> When discussing about possible ways of implementing SSO for API Manager
> 3.0 (C5) we came up with following two approaches,
> In API Manager 3.0, store, publisher and admin apps will be Oauth clients,
> which works with access tokens.
>
> 1. Access token retrieved via SAML grant
>
> - When a user requests a resource, SAML client in the backend will create
> a SAML request and forwards to IDP
> - Once the user logged in to IDP,  SAML response will be sent back to the
> client.
> - SAML response will be then validated and if successful user will be
> logged into the app.
> - Exchange the SAML token to an access token
>
>
> ​
>
> 2. Access token retrieved via Authorization code grant
>
> When a user requests a resource, if he is not authenticated he will be
> redirected to the Authorization server.
> Then user provides username / pwd there and will get an authorization code.
> Then that authorization code is used to obtain the access token and use
> that access token in subsequent calls.
>
>
> Therefore it seems that, there is no real need of using SAML here,
> and implementation wise its much simpler to use 2nd approach as there
> won't be any dependencies for SAML libraries like we had in C4.
>
> Appreciate your thoughts in this
>


I am bit confused by this diagram :)

If I understood correctly, in OIDC flow diagram above the Resource
Server(or rather the OAuth client) would be either Publisher, Store or
Admin portal and the client is something like an agent like browser.

Based on the usual OIDC flow,
Then in step B, the user will be directed to IDP and upon authentication
will get the authorization code(not an access token?) in step D.

Thereafter the resource server usually does a backend call to get the
actual id_token that contain user attributes plus an access token too.

Step E would be the call to userinfo endpoint with the access token get the
user attributes.

In the above diagram in step B the client(browser agent) receives an
authorization code. Can you please explain how this happens?



> ​
> Image reference : https://www.mutuallyhuman.co
> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>
>
> Thanks,
> Sajith
>
> --
> Sajith Kariyawasam
> *Associate Tech Lead*
> *WSO2 Inc.; http://wso2.com *
> *Committer and PMC member, Apache Stratos *
> *AMIE (SL)*
> *Mobile: 0772269575*
>


-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Joseph Fonseka]

On Thu, Mar 30, 2017 at 3:36 PM, Sajith Kariyawasam  wrote:

>
> 2. Access token retrieved via Authorization code grant
>

+1 for the second approach I guess you are suggesting to use OpenID Connect
? I guess the only additional requirement is the user info endpoint [1]

Regards
Jo


[1] http://openid.net/specs/openid-connect-core-1_0.html#UserInfo



>
> When a user requests a resource, if he is not authenticated he will be
> redirected to the Authorization server.
> Then user provides username / pwd there and will get an authorization code.
> Then that authorization code is used to obtain the access token and use
> that access token in subsequent calls.
>
>
> Therefore it seems that, there is no real need of using SAML here,
> and implementation wise its much simpler to use 2nd approach as there
> won't be any dependencies for SAML libraries like we had in C4.
>
> Appreciate your thoughts in this
>
> ​
> Image reference : https://www.mutuallyhuman.co
> m/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
>
>
> Thanks,
> Sajith
>
> --
> Sajith Kariyawasam
> *Associate Tech Lead*
> *WSO2 Inc.; http://wso2.com *
> *Committer and PMC member, Apache Stratos *
> *AMIE (SL)*
> *Mobile: 0772269575*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

-- 
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] [C5] Single sign on support in API Manager 3.0

[Sajith Kariyawasam]

When discussing about possible ways of implementing SSO for API Manager 3.0
(C5) we came up with following two approaches,
In API Manager 3.0, store, publisher and admin apps will be Oauth clients,
which works with access tokens.

1. Access token retrieved via SAML grant

- When a user requests a resource, SAML client in the backend will create a
SAML request and forwards to IDP
- Once the user logged in to IDP,  SAML response will be sent back to the
client.
- SAML response will be then validated and if successful user will be
logged into the app.
- Exchange the SAML token to an access token


​

2. Access token retrieved via Authorization code grant

When a user requests a resource, if he is not authenticated he will be
redirected to the Authorization server.
Then user provides username / pwd there and will get an authorization code.
Then that authorization code is used to obtain the access token and use
that access token in subsequent calls.


Therefore it seems that, there is no real need of using SAML here,
and implementation wise its much simpler to use 2nd approach as there won't
be any dependencies for SAML libraries like we had in C4.

Appreciate your thoughts in this

​
Image reference : https://www.mutuallyhuman.com/blog/2013/05/09/choosing-
an-sso-strategy-saml-vs-oauth2/


Thanks,
Sajith

-- 
Sajith Kariyawasam
*Associate Tech Lead*
*WSO2 Inc.; http://wso2.com *
*Committer and PMC member, Apache Stratos *
*AMIE (SL)*
*Mobile: 0772269575*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture