On Sat, Apr 1, 2017 at 1:39 AM, Farasath Ahamed <[email protected]> wrote:
> > > On Thursday, March 30, 2017, Sajith Kariyawasam <[email protected]> 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 <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 <https://twitter.com/farazath619> > <http://wso2.com/signature> > > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Bhathiya Jayasekara* *Associate Technical Lead,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *LinkedIn: http://www.linkedin.com/in/bhathiyaj <http://www.linkedin.com/in/bhathiyaj>* *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* *Blog: http://movingaheadblog.blogspot.com <http://movingaheadblog.blogspot.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
