# A Dynamic Federated Identity Management Using OpenID Connect
## 4 Experimental Environment and Implementation
### Dynamic OIDC Provider Discovery  
We assume that AdvertiseMe is a company that has its users stored in ADFS and is capable of providing claims to clients or relying parties. FlyerIT is a web application that provides web services and its resources requires users to login using any of the supported identity providers. We assume that [PERSON] has never used the FlyerIt tool before. If [PERSON] wants to use his AdvertiseMe identity to log in to the tool, how would the tool know who is the identity provider of [PERSON] to authenticate him? Dynamic discovery helps FlyerIt as an RP to dynamically allocate an end-user's identity provider. The discovery process is important so that the RP can obtain the OP information needed for interaction (e.g., registration and authorization) with the identity provider. The discovery process is the first process towards achieving a dynamic identity federation environment. This step is initiated only once. Once an RP has discovered the IdP of a specific host, the RP is able to serve end-users coming from the same host indefinitely. Dynamic discovery is possible through the use of WebFinger [19] to locate the OP for a specified end-user.  
Figure 1 depicts the sequence diagram that defines the steps for FlyerIt to achieve the dynamic discovery of AdvertiseMe.  
1. Dynamic discovery is triggered whenever a user requests a sign-in from an RP in order to access their resources and services. [PERSON] is the initiator of this process when he triggers the FlyerIt RP for a custom sign-in using his company's credentials.
2. The RP (FlyerIt) requests the end-user to provide an identifier, which is necessary so that the RP can extract the resource and the host. In our scenario, the RP requests [PERSON] to provide an identifier.
3. The end-user provides an identifier to the RP. The RP accepts an email address as an identifier. Now, [PERSON] provides his email address [EMAIL_ADDRESS] to the RP (FlyerIt).
4. The RP extracts the identifier provided by the end-user and applies a normalization in order to determine the resource and host values. FlyerIt extracts [PERSON]'s email and determines that the resource is equal to [PERSON], and the host is equal to advertisement.com.
GET /.well-known/webfinger  
?resource=acct:[EMAIL_ADDRESS]  
&rel=[[http://openid.net/specs/connect/1.0/issuer](http://openid.net/specs/connect/1.0/issuer)]([http://openid.net/specs/connect/1.0/issuer](http://openid.net/specs/connect/1.0/issuer))  
HTTP/1.1  
Host:advertiseme.com  
Figure 1: OIDC Dynamic Discovery Model.  
Once the OP receives the request, it figures out the issuer of the provided resource and returns it to the RP as a WebFinger response as depicted below. The WebFinger response contains a links array that consists of a rel and href values for the specified subject. The rel indicates the type of location returned, which is an issuer location in our case. The href is the _URL_ of the specified issuer.  
HTTP/1.1 200 OK Content-Type: application/jrd+json { \"subject\": \"acct:[EMAIL_ADDRESS]\", \"links\": [{ \"rel\": \"[[http://openid.net/specs/connect/1.0/issuer](http://openid.net/specs/connect/1.0/issuer)]([http://openid.net/specs/connect/1.0/issuer](http://openid.net/specs/connect/1.0/issuer))\", \"href\": \"[[https://identity.advertiseme.com](https://identity.advertiseme.com)]([https://identity.advertiseme.com](https://identity.advertiseme.com))\" } } As a result of the steps defined previously, the RP has successfully discovered the location of the IdP of the end-user. FlyerIt, in our case, has discovered the locations of [PERSON]'s OP. As a result, FlyerIt is able to register itself with AdvertiseMe and authenticate [PERSON] to access its resources.