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] Shall we add gateway health check capability

[Bhathiya Jayasekara]

On Mon, Mar 27, 2017 at 8:48 PM, Imesh Gunaratne  wrote:

>
>
> On Wed, Feb 1, 2017 at 12:24 PM, Nuwan Dias  wrote:
>
>>
>> 2) The gateway interceptors should ignore requests to this endpoint. i.e,
>> security, throttling, analytics, etc should be ignored.
>>
>
> Wouldn't this allow to perform DoS attacks on the gateway if no
> interceptors are applied? May be we would at least need a curcuit breaker
> for this endpoint to avoid such attacks. WDYT?
>

Do we really need to consider this here as this special API does not call
anything beyond the gateway? IMO we don't have to.

Thanks,
Bhathiya


>
> Thanks
> Imesh
>
>
>> Thanks,
>> NuwanD.
>>
>> On Wed, Feb 1, 2017 at 12:05 PM, Rushmin Fernando 
>> wrote:
>>
>>> +1
>>>
>>> Other than sending back 200, I think it would be helpful if there is
>>> another configuration to make the health check API, call a given backend
>>> (which returns 200) and respond to the original caller.
>>>
>>> The advantage of having this is, we can have a rough idea about the full
>>> flow. e.g. is traffic going out from the gateway node to outside networks?
>>>
>>> On Wed, Feb 1, 2017 at 11:44 AM, Lakmal Warusawithana 
>>> wrote:
>>>
 Hi,

 When we deploying api gateway in container management system (or even
 fronted by ELB) we need to have a health check end point to configure.
 Since gateway only going pass through we don't have such at the moment.

 Shall we do $subject? it should only return 200

 thanks

 --
 Lakmal Warusawithana
 Director - Cloud Architecture; WSO2 Inc.
 Mobile : +94714289692 <+94%2071%20428%209692>
 Blog : http://lakmalsview.blogspot.com/


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


>>>
>>>
>>> --
>>> *Best Regards*
>>>
>>> *Rushmin Fernando*
>>> *Technical Lead*
>>>
>>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>>
>>> mobile : +94775615183
>>>
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Software Architect - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Software Architect
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>
> ___
> 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