I have tried to find but without any success on how to use Windows authentication that is implemented in IdentityServer4 samples (Quickstart6: AspNetIdentity).
What I managed to find out is that I can use http://localhost:5000/connect/token to POST client_id, client_secret, scope and grant_type in order to get token. The issue is next. From what I have managed to find out in order to use Windows authentication, I need to use "hybrid" for grant_type, but I always get "unsupported_grant_type".
Since I want to avoid default MVC client that is in that example to work with Windows authentication, how can I use Windows authentication trough rest with provided username/email and password, so I can make my own login page for Windows authentication in for example React application?
I have also found http://localhost:5000/connect/authorize endpoint, but I don't know if I can use it for this and how to even work with that endpoint.
I'd suggest reading more about OpenID connect in general to familiarise yourself with the various flows.
When working in a Windows context I'd recommend using ADFS. The latest version supports OpenID Connect out of the box so is a doddle to integrate with from ASP.Net Core whereas the other options (direct LDAP calls or IIS integration) are more complex and/or restrictive.
That said, this article covers how to use integrated Windows auth when running in IIS on Windows: https://docs.identityserver.io/en/release/topics/windows.html
Related
I would like to check if my understanding is correct about the way to use Keycloak.
After Keycloak server is installed and running, we would have 2 options:
Use the javascript adapter in the application we want to authenticate
Use the mod_auth_openid to use Keycloak with Apache webserver
In the case of web application, since it must have an web server, does it mean only option 2 is available? And even if option 1 is available, should I use it?
It depends on the type of your application. If you want to provide your application as SPA (Single Page Application) using JavaScript, JavaScript Adapter will be good option. But if you want to provide it as traditional server-side web application which doesn't support standard federation protocol like OpenID Connect, mod_auth_openidc will fit.
Also keycloak provides several types of client adapters. You can check them with the following document.
https://www.keycloak.org/docs/latest/securing_apps/index.html#supported-platforms
In addition, if your application is already OpenID Connect or SAML 2.0 compliant, you can integrate with keycloak server without any client adapters because it based on open standard protocol which keycloak supports. Please refer the following document to understand securing your application.
https://www.keycloak.org/docs/latest/securing_apps/index.html#overview
Be warned possibly noob question ahead.
I'm a little unsure where exactly Azure AD or IdentityServer is supposed to fit in in the overall communication flow.
Here is a scenario that I often face.
Some "dumb" client (e.g. a Windows App that can't use external assemblies or some JavaScript in a web app) has to contact my Web API which will then contact other APIs or other resources.
If I want to try and implement either Azure AD or IdentityServer as a means of authentication and authorization in the Web API, I don't see that this can be done in any other way, than it has to be the Web API that communicates with Azure AD or IdentityServer as the client doesn't have the ability to do so due to the lack of required assemblies.
If this assumption is not correct, then how would I do this?
If it is correct however, then what means of security is there between the client and the Web API other than communicating over HTTPS when the client has to send it's credentials to the Web API, so the Web API can authenticate and authorize the user against either Azure AD or IdentityServer?
If I understand your requirements correctly, then you are able to change the client Windows app, but unable to add external assemblies to it? So you would not be able to add the ADAL NuGet package to it.
You can still use Azure AD authentication - it is possible, but not trivial, to implement the client code yourself.
Or you can, as you already mentioned, pass the user's credentials to the Web API somehow, and then use that to have the Web API do authentication towards Azure AD on behalf of the user. There is a sample app which shows how to use username/password credentials.
This however, goes against the whole OAuth/OpenIdConnect mindset, where your app should never know the user's credentials.
Here:
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/develop/active-directory-v2-protocols-oidc.md
Be careful with trying to use the most recent version of the Azure AD endpoint (just don't use version 2.0, they shot themselves in the foot by excluding all Azure AD webapp registrations & by "securing" web APIs by making them only available to apps with the same appid - as far as I'm concerned, it's unusable until they fix those two issues) - see the "[!NOTE]" near the top of that linked page for the v2.0 limitations.
So we are using IdentityServer4 for our web applications, all is good.
We have a new requirement from a client to allow them to perform SSO via their ADFS system using WsFederations, we already provide this for another one of our older web applications that is not tied into IdentityServer4 yet.
Ideally we would like to tie WsFedereration into IdentityServer4 so it is in one place.
Does anyone know if it possible to use IdentityServer4, so we redirect to IdentityServer4, identity that this particular client (possibly via an alternative URL), then IdentityServer4 authenticates against ADFS, collects the claims (probably basic, e.g. email/username/etc) , and we then supplement them with additional claims for access, and pass back to the web application.
What I'm trying to achieve ideally is to not change the existing Web Application, and to sort the plumbing at IdentityServer4, and the Web Application wouldn't know or care if this user was IdentityServer4 only or
IdentityServer4 + WsFederation. This would be useful for other clients across our applications to easily integrate in the future.
Alternatively I could deploy another version of the Web Application that authenticates directly with my clients ADFS system. However this seems a waste of server resources/maintenance for just one small client.
I had a look at the external options (where you click google on or near the IdentityServer4 Login Screen), is there a way to automatically redirect to the ADFS without event seeing the IdentityServer4 implemented Login screen.
Is this possible?
Thanks,
Jon
This was released 2017, see the example at
https://github.com/IdentityServer/IdentityServer4.WsFederation
I would like to authenticate users against Active Directory using LDAP. Is it possible with OpenIddict ?
Currently, I have Front end (Angularjs) + Back end (Web.API with ASP.NET Core and OpenIddict) which works perfect. Part of users use individual user accounts and they will continue. Another part of users should use AD accounts. It is inside internal network and would like to use already existing Active Directory for that.
Please suggest any solutions for that.
Thanks.
Please suggest any solutions for that.
OpenIddict is never responsible of the login/authentication part, so you can freely implement it to use LDAP with both interactive flows like the code flow and with non-interactive flows like the password flow.
If your AD servers can run Active Directory Federation Services, I'd recommend using it, as it's the best way to achieve what you want.
Depending on the version you're using, you'll be able to integrate with any ASP.NET Core app quite easily (the 2016 version supports OpenID Connect while the previous one supports OAuth2: both can be used with the OAuth2/OIDC middleware developed by the ASP.NET team).
If you can't use ADFS, another option is to use Integrated Windows Authentication. It's currently only supported when hosting your application behind IIS or when using WebListener.
If none of these options work for your scenario, you can opt for the "low-level LDAP validation" route. Though it's not officially supported by .NET Core, there are a few libraries developed by the community that you can use: https://github.com/dotnet/corefx/issues/2089#issuecomment-231994908.
I am looking to create a WCF (possibly WebApi) web service that sits on top of some of our existing code. Eventually this service will be used by external clients but we are going to start using it with our own mobile app.
As some clients will want to use Gmail and ADFS authentication it seems to make sense to use Azure ACS (this is where our webservices are hosted). However we won't need multiple providers for a while and we will start by using a custom STS that authenticates users against our existing authentication logic.
We already have a rough prototype of the above working using a MVC web application acting as the client.
My problem is how do I integrate this with a mobile application? It looks as if the mobile app will be written using AppCelerator which means I need to authenticate using javascript. We only want users to authenticate to our custom STS so would I need to use Active Authentication? I.e.
Ask user to enter username and password
Directly authenticate with custom STS and retrieve token
Pass STS token to ACS and retrieve ACS token
Pass ACS token to wcf service for each request.
I guess my questions are: am I on the right track and if so how would I achieve this in javascript?
If you want to support mobile devices, it is recommended to provide a web based login interface in your STS. In most cases, a mobile device will navigate to your STS’s sign in page in a web browser. After your STS authenticates the user, it sends claims to ACS. ACS in turn uses JavaScript notification to notify the host application.
You can refer to http://msdn.microsoft.com/en-us/WAZPlatformTrainingCourse_ACSAndWindowsPhone7 for a tutorial about working with ACS in Windows Phone. Similar process can be used for other mobile devices.
Hope this helps.
I think it is possible to issue SAML over Https request. As a starting point Id suggest to look at Thinktecture IdentityServer sources by Dominick Baier. This will help to understand different strategies and how you can use em(there are some goodies for WebApi on Github also):
http://identityserver.codeplex.com/