On Wed, Apr 5, 2017 at 9:04 AM, Harsha Thirimanna <[email protected]> wrote:
> > > On Apr 1, 2017 10:37 PM, "Farasath Ahamed" <[email protected]> wrote: > > > > > > On Sat, Apr 1, 2017 at 11:27 AM, Bhathiya Jayasekara <[email protected]> > wrote: > >> >> >> 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. >> > > 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 <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 <+94%2071%20547%208185>* >> *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 >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933 +358 449 228 979 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
