Hi, Please find the PR for above at [1]
[1] https://github.com/wso2/carbon-identity/pull/824 Thanks. On Wed, Dec 23, 2015 at 5:15 AM, Chamara Philips <[email protected]> wrote: > Hi all, > Currently we don't have the facility of using OpenID Connect Discovery to > get the OpenID Provider information needed to interact with it, including > its OAuth 2.0 endpoint locations. I have implemented this facility for IS, > as it is described at [1]. The implemented code can be found at [2]. This > will help in solving the "Discovery Problem" [3] of the Service Provider. > > As described at the specification [4], it has two main services to be > provided by the Identity Server side in order to implement the OpenID > Connect Discovery. > > > 1. Web Finger Service for OpenID Provider Issuer Discovery > 2. An endpoint to provide OpenID Provider Configuration > > These two services are independent. > > The final target of the process is to get the OpenID Provider > Configuration metadata, such as issuer, authorization_endpoint, > token_endpoint, userinfo_endpoint etc. (as further described in the [1]). > The respond will be a json document including all the configuration. For > this to happen the service provider should SOMEHOW know the endpoint which > provide OpenID Provider Configuration. Web Finger Service is ONE way of > doing this. So, in the Service Provider point of view the service required > from the first service may be optional. > > If the service provider has to request the Web Finger Service to get to > know OpenID Provider Issuer the end point of the Web Finger Service should > be known by the user. This is required to be done by an identifier provided > by the end-user. This identifier is normalized by the service provider to > find out the Web Finger host, where the users OpenID Provider Issuer can be > discovered. [1] Or else the Service Provider, based on its application > design, may require the users' OpenID Provider Configuraiton to be found at > one place. (Ex: When there is no federation). Or a browser plugin instead > of user may provide this to the Service Provider. However, AFAIU this > matter is upto the Service Provider to decide.[4] > > From the Identity Server point of view it is noteworthy to point that > there is no connection between these two services and their responds. > > The designed architecture and workflow is further discussed in [1]. > > [1] > https://docs.google.com/document/d/10WGDzCBSCk6DPeiUNcvLbZIzmyDAMkQLJ-TUHJi104E/ > [2] > https://github.com/ChamaraPhilipsuom/carbon-identity/tree/OpenID-Connect-Discovery > [3] > http://hareendracsespace.blogspot.com/2015/12/the-discovery-problem.html > [4] https://openid.net/specs/openid-connect-discovery-1_0.html > > > Any suggestions and ideas for improving this feature is highly welcome. > > Thanks & Regards > -- > Hareendra Chamara Philips > *Software Engineer* > Mobile : +94 (0) 767 184161 <%2B94%20%280%29%20773%20451194> > [email protected] <[email protected]> > > -- Hareendra Chamara Philips *Software Engineer* Mobile : +94 (0) 767 184161 <%2B94%20%280%29%20773%20451194> [email protected] <[email protected]>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
