You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 18, 2021. It is now read-only.
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/",
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: