Error in ASP.NET MVC Sample

[MuruganSiva]

Hi,

Thank you for creating this library. I just cloned the sample ASP.Net 5 project and tried to ran the app with my own keycloak server settings. For the first time I received an exception related to the "audience" validation, since I dont need that I just disabled that using the property "DisableAudienceValidation". Now I am getting another exception related to SecurityKeyIdentifier.

Could you please let me know what is missing?

The exception is as below.

IDX10500: Signature validation failed. Unable to resolve SecurityKeyIdentifier: 'SecurityKeyIdentifier
(
IsReadOnly = False,
Count = 1,
Clause[0] = System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause
)
',
token: '{"alg":"HS256","typ":"JWT","kid":"4718be89-a61c-4007-b355-6c85319c9c9f"}.{"jti":"8635361e-7825-40d9-94a4-faae4b3fe264","exp":1565278106,"nbf":0,"iat":1565276306,"iss":"http://localhost:8080/auth/realms/master","aud":"http://localhost:8080/auth/realms/master","sub":"dd09c01c-be26-48b6-9942-efc0b1abc3b6","typ":"Refresh","azp":"sampleclient","auth_time":0,"session_state":"a59830f0-9fd2-4bf4-ae74-7dda461aab0f","realm_access":{"roles":["offline_access","uma_authorization"]},"resource_access":{"account":{"roles":["manage-account","manage-account-links","view-profile"]}},"scope":"openid email profile"}'.

[MuruganSiva]

Update..

The issues seems to be resolved once I change the keycloak server settings to use the access type as "public" instead of "confidential" in the client configuration.

[RiadKatby]

I have the same, and even when I change the access type to public didn't work "AuthenticationException" is thrown then.

any help?

[ryanspletzer]

This middleware was written while Dylan was an intern at our company where neither of us work anymore... It's no longer being maintained and as Keycloak increments versions and people move to ASP.NET Core and more OpenID Connect standards / extensions get put in place it will just continue to break more.

Microsoft has really good and pretty flexible middleware for OIDC and OAuth Bearer token validation for ASP.NET Core that people should take a look at. And I believe they even finally picked back up and updated their Katana OWIN middleware for full framework ASP.NET.

[MuruganSiva]

Hi Ryan, Thanks for the reply. In my case, we have some old .NET applications (.Net Framework 4.6). I understand that using ASP.NET core makes things easy for OIDC but do you think it is a good idea to use this library for a PROD application if we want to avoid reinvent the wheel? Please suggest if there is any inbuilt .NET library which can do the same with little additional work. Also there is a JavaScript adapter available from keycloak. Is it safe to use? Siva

…

On Fri, Sep 6, 2019 at 5:40 PM Ryan Spletzer ***@***.***> wrote: This middleware was written while Dylan was an intern at our company where neither of us work anymore... It's no longer being maintained and as Keycloak increments versions and people move to ASP.NET Core and more OpenID Connect standards / extensions get put in place it will just continue to break more. Microsoft has really good and pretty flexible middleware for OIDC and OAuth Bearer token validation for ASP.NET Core that people should take a look at. And I believe they even finally picked back up and updated their Katana OWIN middleware for full framework ASP.NET. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54?email_source=notifications&email_token=AGJLJ3IQR3EB7Y2ZHTNE733QILE5LA5CNFSM4IKLPV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6EEC4A#issuecomment-529023344>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGJLJ3MPIRLJ5ZG42WEMGWDQILE5LANCNFSM4IKLPV3Q> .

[ryanspletzer]

Hi Siva,

Take a look at the resurrected Katana Middleware for full framework ASP.NET. One of the big reasons this Keycloak-specific middleware was developed in the first place was because the Katana middleware from Microsoft had become stagnant / not updated anymore. Then a year or so ago they brought it back to life and moved it from CodePlex to GitHub and are maintaining and updating it again. Between the Microsoft.Owin.Security.Jwt and Microsoft.Owin.Security.OpenIdConnect middleware you should be able to accomplish the same results.

https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/

https://github.com/aspnet/AspNetKatana

[MuruganSiva]

Thanks again Ryan. If my understanding is correct, you are recommending to use the restructured Katana Middleware to build our own custom library for keycloak SSO. Correct? Just another quick question, how do we ensure that all required features for a SSO workflow is met? I am just worried about missing any critical workflow which is part of SSO. That is the reason I went with a library which is already built and tested. Siva

…

On Mon, Sep 16, 2019 at 11:42 AM Ryan Spletzer ***@***.***> wrote: Hi Siva, Take a look at the resurrected Katana Middleware for full framework ASP.NET. One of the big reasons this Keycloak-specific middleware was developed in the first place was because the Katana middleware from Microsoft had become stagnant / not updated anymore. Then a year or so ago they brought it back to life and moved it from CodePlex to GitHub and are maintaining and updating it again. Between the Microsoft.Owin.Security.Jwt and Microsoft.Owin.Security.OpenIdConnect middleware you should be able to accomplish the same results. https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/ https://github.com/aspnet/AspNetKatana — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54?email_source=notifications&email_token=AGJLJ3LH6KTLQ7II45ET7LTQJ6SPNA5CNFSM4IKLPV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6ZSSTI#issuecomment-531835213>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGJLJ3M4MH2BLUIXUZALIYDQJ6SPNANCNFSM4IKLPV3Q> .

[ryanspletzer]

Thanks again Ryan. If my understanding is correct, you are recommending to use the restructured Katana Middleware to build our own custom library for keycloak SSO. Correct?

Correct, but it's not custom, you're just using their middleware. It also depends on what you want. If you're building a same origin SPA then use Owin.Security.OpenIDConnect middleware and also likely the Cookie middleware, it'll get everything you need. If your API is not hosted on the same origin and you want to do CORS for your SPA (say it's a static SPA served up from S3 / Azure Storage) then you need to look into OpenID Connect libraries for JavaScript to help facilitate this like this:

https://github.com/IdentityModel/oidc-client-js

And for your standalone API use the Jwt middleware from Katana.

The Owin Middleware is lego pieces that you can pick and choose whereas this one was "all-in-one" bundled together. Yes, it may be harder to get going, but it's actually supported where this is not.

Just another quick question, how do we ensure that all required features for a SSO workflow is met? I am just worried about missing any critical workflow which is part of SSO. That is the reason I went with a library which is already built and tested. Siva

Microsoft's middleware is tested way more than this, I assure you. Also if you follow the guidance above you should be covered.

[MuruganSiva]

Thank you Ryan. This is really helpful.

…

On Mon, Sep 16, 2019 at 6:02 PM Ryan Spletzer ***@***.***> wrote: Thanks again Ryan. If my understanding is correct, you are recommending to use the restructured Katana Middleware to build our own custom library for keycloak SSO. Correct? Correct, but it's not custom, you're just using their middleware. It also depends on what you want. If you're building a same origin SPA then use Owin.Security.OpenIDConnect middleware and also likely the Cookie middleware, it'll get everything you need. If your API is not hosted on the same origin and you want to do CORS for your SPA (say it's a static SPA served up from S3 / Azure Storage) then you need to look into OpenID Connect libraries for JavaScript to help facilitate this like this: https://github.com/IdentityModel/oidc-client-js And for your standalone API use the Jwt middleware from Katana. The Owin Middleware is lego pieces that you can pick and choose whereas this one was "all-in-one" bundled together. Yes, it may be harder to get going, but it's actually supported where this is not. Just another quick question, how do we ensure that all required features for a SSO workflow is met? I am just worried about missing any critical workflow which is part of SSO. That is the reason I went with a library which is already built and tested. Siva Microsoft's middleware is tested way more than this, I assure you. Also if you follow the guidance above you should be covered. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54?email_source=notifications&email_token=AGJLJ3NBHLJ5KB446OHIHQDQJ7673A5CNFSM4IKLPV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62U4TA#issuecomment-531975756>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGJLJ3LQMDKDCAHIOBYT4BDQJ7673ANCNFSM4IKLPV3Q> .

[MuruganSiva]

Ryan, I am able to understand most part of your email. My requirement is same origin, so I can actually use openid connect middleware and cookie middleware. I am able to do the redirection successfully to my identity provider but after authentication i didn't see the Identity object populated with the user details. In another words, how do I retrieve the logged in user details from the claims object. This is my startup file. app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); app.UseCookieAuthentication(new CookieAuthenticationOptions()); app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { Authority = "http://localhost:8080/auth" + "/realms/" + "master", ClientId = "sample", PostLogoutRedirectUri = "http://localhost:37091/", Scope = "openid", ResponseType = "code", RedirectUri = "http://localhost:37091/", RequireHttpsMetadata = false } ); Am I missing something here? (Should I use JWT middleware in this scenario??) Any help is appreciated. Siva

…

On Mon, Sep 16, 2019 at 6:02 PM Ryan Spletzer ***@***.***> wrote: Thanks again Ryan. If my understanding is correct, you are recommending to use the restructured Katana Middleware to build our own custom library for keycloak SSO. Correct? Correct, but it's not custom, you're just using their middleware. It also depends on what you want. If you're building a same origin SPA then use Owin.Security.OpenIDConnect middleware and also likely the Cookie middleware, it'll get everything you need. If your API is not hosted on the same origin and you want to do CORS for your SPA (say it's a static SPA served up from S3 / Azure Storage) then you need to look into OpenID Connect libraries for JavaScript to help facilitate this like this: https://github.com/IdentityModel/oidc-client-js And for your standalone API use the Jwt middleware from Katana. The Owin Middleware is lego pieces that you can pick and choose whereas this one was "all-in-one" bundled together. Yes, it may be harder to get going, but it's actually supported where this is not. Just another quick question, how do we ensure that all required features for a SSO workflow is met? I am just worried about missing any critical workflow which is part of SSO. That is the reason I went with a library which is already built and tested. Siva Microsoft's middleware is tested way more than this, I assure you. Also if you follow the guidance above you should be covered. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54?email_source=notifications&email_token=AGJLJ3NBHLJ5KB446OHIHQDQJ7673A5CNFSM4IKLPV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62U4TA#issuecomment-531975756>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGJLJ3LQMDKDCAHIOBYT4BDQJ7673ANCNFSM4IKLPV3Q> .

[MuruganSiva]

Also my scenario doesn't involve any WEB API authentication. I am just rewriting my application authentication from "Forms based" model to use SSO based.

…

On Tue, Sep 17, 2019 at 4:12 PM Siva Murugan ***@***.***> wrote: Ryan, I am able to understand most part of your email. My requirement is same origin, so I can actually use openid connect middleware and cookie middleware. I am able to do the redirection successfully to my identity provider but after authentication i didn't see the Identity object populated with the user details. In another words, how do I retrieve the logged in user details from the claims object. This is my startup file. app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); app.UseCookieAuthentication(new CookieAuthenticationOptions()); app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { Authority = "http://localhost:8080/auth" + "/realms/" + "master", ClientId = "sample", PostLogoutRedirectUri = "http://localhost:37091/", Scope = "openid", ResponseType = "code", RedirectUri = "http://localhost:37091/", RequireHttpsMetadata = false } ); Am I missing something here? (Should I use JWT middleware in this scenario??) Any help is appreciated. Siva On Mon, Sep 16, 2019 at 6:02 PM Ryan Spletzer ***@***.***> wrote: > Thanks again Ryan. If my understanding is correct, you are recommending > to use the restructured Katana Middleware to build our own custom library > for keycloak SSO. Correct? > > Correct, but it's not custom, you're just using their middleware. It also > depends on what you want. If you're building a same origin SPA then use > Owin.Security.OpenIDConnect middleware and also likely the Cookie > middleware, it'll get everything you need. If your API is not hosted on the > same origin and you want to do CORS for your SPA (say it's a static SPA > served up from S3 / Azure Storage) then you need to look into OpenID > Connect libraries for JavaScript to help facilitate this like this: > > https://github.com/IdentityModel/oidc-client-js > > And for your standalone API use the Jwt middleware from Katana. > > The Owin Middleware is lego pieces that you can pick and choose whereas > this one was "all-in-one" bundled together. Yes, it may be harder to get > going, but it's actually supported where this is not. > > Just another quick question, how do we ensure that all required features > for a SSO workflow is met? I am just worried about missing any critical > workflow which is part of SSO. That is the reason I went with a library > which is already built and tested. Siva > > Microsoft's middleware is tested way more than this, I assure you. Also > if you follow the guidance above you should be covered. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#54?email_source=notifications&email_token=AGJLJ3NBHLJ5KB446OHIHQDQJ7673A5CNFSM4IKLPV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62U4TA#issuecomment-531975756>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGJLJ3LQMDKDCAHIOBYT4BDQJ7673ANCNFSM4IKLPV3Q> > . >