Skip to content
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.

Having an issue with MVC Hybrid flow #958

Closed
kkfrosty opened this issue Feb 21, 2015 · 2 comments
Closed

Having an issue with MVC Hybrid flow #958

kkfrosty opened this issue Feb 21, 2015 · 2 comments

Comments

@kkfrosty
Copy link

I've taken the MVC Client Hybrid flow example and got it working with IIS just fine.

However, I've tried to take everything from that environment and setup another application that was already in place. That application was created off the base MVC template. It has NinJect integrated to load areas but it's basic. I've also tested commenting out the Ninject code.

The issue is I never seem get authenticated or a ClaimsPrincipal generated on the client. I thought it was something with OWIN. However, over a day troubleshooting, I've going to an exception with UserInfoClient.

Value cannot be null.
Parameter name: token
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentNullException: Value cannot be null.
Parameter name: token
Source Error:

Line 88: // n.ProtocolMessage.AccessToken);
Line 89:
Line 90: var userInfoClient = new UserInfoClient(
Line 91: new Uri("https://localhost/IdentityApis/core/connect/userinfo/"),
Line 92: n.ProtocolMessage.AccessToken);
Source File: c:\TFS\SL\sl-hv01\SmartLogix\SmartLynx\SmartLynx\UI\Trunk\SL.Main\App_Start\Startup.Auth.cs Line: 90

[ArgumentNullException: Value cannot be null.
Parameter name: token]
Thinktecture.IdentityModel.Client.UserInfoClient..ctor(Uri endpoint, String token, HttpClientHandler innerHttpClientHandler) in c:\etc\Dropbox\thinktecture\IdentityModel\source\Client.Shared\UserInfoClient.cs:22
SL.Main.<b__3>d__c.MoveNext() in c:\TFS\SL\sl-hv01\SmartLogix\SmartLynx\SmartLynx\UI\Trunk\SL.Main\App_Start\Startup.Auth.cs:90

When i started this thread, if I set a break point on the var userInfoClient = new UserInfoClient(.....) n is populated and n.ProtocalMessage.AccessToken had a value.
At this point in this post, I stepped through again to get the value of the token and now it's null.

The first question is how could n.ProtocalMessage.AccessToken be null? I've checked the Identity Server logs and I don't see any errors, exceptions etc. Looks like everything is processing fine.

Here's another piece of information that has me puzzled. When initializing the app.UseOpenIdConnectAuthentication and setting the RedirectUri & PostLogoutUri, if I add a / to the end of the URI,
RedirectUri = "http://localhost/SLMain/",
PostLogoutRedirectUri = "http://localhost/SLMain/",

the breakpoint I set for
var userInfoClient = new UserInfoClient(
new Uri("https://localhost/IdentityApis/core/connect/userinfo/"),
n.ProtocolMessage.AccessToken);
hits and I get the exception.

If I remove the /
RedirectUri = "http://localhost/SLMain",
PostLogoutRedirectUri = "http://localhost/SLMain",

then the breakpoints are never hit. I get no errors but when I click on a link that redirects to a Controller method with the [Authorize] attribute, the application just go back to the home index which doesn't have the authorize attribute. If you set a break point in the controller, there is no ClaimPrincipal, no user and obviously it's not authenticated.

However, again on the server side the logs show a user authenticate, authorize logs I don't see any errors that stand out.

Also, not sure if it makes a difference but for the URI property in UserInfoClient, I have to enter the full URL. If I just add /connect/userinfo like in the client sample, then UserInfoClient instantiation throws an invalid URI exception. The Authority property gets set as
https://localhost/IdentityApis/core which is correct.

Also, this code that runs just before the instantiation of _userInfoClient, claims get populated with the claims that's assigned to the logged on user.
// filter "protocol" claims
var _claims = new List(from c in n.AuthenticationTicket.Identity.Claims
where c.Type != "iss" &&
c.Type != "aud" &&
c.Type != "nbf" &&
c.Type != "exp" &&
c.Type != "iat" &&
c.Type != "nonce" &&
c.Type != "c_hash" &&
c.Type != "at_hash"
select c);
The sample described in this is what I'm following.
http://leastprivilege.com/page/2/

AuthorizationCodeReceived which is where n => is derived from has a JWT Token, AuthenticationTicket etc. For some reason n.ProtocalMessage.AccessToken is now null every time.

To recap, if I remove the / from the end of the RedirectUri & PostLogoutUri, then the break points inside of Notifications = new OpenIdConnectAuthenticationNotifications never hit.

There are no exceptions but in the UI application a user is never authenticated. (Again in this scenario, on the server side you can see the authentication from the login page, even going to a page where the controller has the authorize attribute, I seem to see the authorization in the identity server logs, yet in the UI web, their is no ClaimsPrincipal thus no permissions.

@kkfrosty
Copy link
Author

Ok, I've got past the ProtocolMessage.AccessToken being null. The issue, in researching and following suggestions in another post, I commented out the code that defined ResponseType.
I went back and enabled that so REsponseType is now code id_token token and it resolved this problem.

Also, not my initial problem appears to be because the / was missing at the end of the RedirectUri & PostLogoutRedirectUri. However, that caused no problems other than a claims principal was never generated at the client side. Even though the logs in the server looked fine.

The only way I figured this out was setting break points in the Startup inside the Notification definition. They were never getting hit.

@mleitao
Copy link

mleitao commented Apr 5, 2016

@kkfrosty thanks for the answer I had the same issue and setting
ResponseType = "code id_token token",

Worked for me as well

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants