I am working on client server application with following details:
Client(C++) -----------HTTPS--- Server (C#/WCF)
Server:
With Users in windows Active Directory domain
WCF service running in IIS providing authentication service against windows AD
Provides REST based authentication API which uses windows API logonUser.
Client:
Client uses REST SDK (Visual Studio 2013 based) to connect server
Client provides authentication API for authentication using HTTPS.
Currently I am working to authenticate windows user logged-in in client at server:
AD user logs in to client and invoke the authentication API
The current logged in user details have to be sent to Server using HTTPS ( of course only username)
Create WindowsIdentity structure with the information retrieved from the client.
I have tried following:
To get the SID from the client machine and pass it to server. Recreate the WindowsIdentity from the SID of client login.
I could not get the WindowsIdentity from the SID passed.
Questions:
How to get the windows identity in server (C#) from the SID of the logged in AD User passed from the client?
Are there any other better ways to achieve the above setup?
have you tried
ServiceSecurityContext.Current.WindowsIdentity.Name
but there is no way of converting the username format without involving a query to Active Directory. Since that is the case there is no need to create WindowsPrincipal for checking the group membership since that would probably need yet another connection to AD.
try to use the solution provided in this link
Related
I am trying to better understand the OpenID Connect protocol with IdentityServer4, and am unclear on where I can find the answer to this question.
I like the idea of the Identity Server providing a Bearer Token at the end of authentication that includes claims on who the user is, and what resources they can access. However, I am a little uncomfortable in storing what Resources a user may have access to within the Identity Server environment. I would like this Authorization piece to be authored at my client application. Is there any type of callback in the OpenID callback that allows IdentityServer to call the client and request Authorization Claims from the client directly, rather than piece it together directly?
As an example, I am working on a product that will require a user to log in using either Windows Authentication, Username/Password, or a Google Account.
This client application will be hosted in a cloud environment, and will be hosted in the same domain as the Active Directory Server.
My thought was to create an Identity Server solution that is hosted internally, and to create a Client application that is hosted in the cloud.
When the user logs into the Client application, they would be redirected to the Identity Server to log in. The Identity Server would be hosted in the same domain as the Active Directory Server, so if there were Windows Credentials we could log them in automatically. Otherwise, there will be a login screen where they can enter a Username/Password, log in with Google, etc.
Once the user has logged in, the Identity Server would return a Bearer Token (a JWT probably), that has their claim information.
I can foresee this one Identity Server being used by many different Client application, because it would intrinsically allow Windows Authentication. For this reason, I am hesitant to store all of the API Resources the user can access within the Identity Server itself. My fear is that if I add a new permission to my client application (like a Report Admin claim), I would need to modify the Identity Server to include that new claim. And if 4 or 5 clients all use this Identity Server, this could get to be a bit onerous.
Instead, I would like to structure Identity Server so that when a user logs in for a particular client, Identity Server will make a callback request to the Client Application asking for the Claims that apply to that user. That way, the Client Application knows and cares about the User/Claim mappings, not the Identity Server. If I need to add a new Claim, I can do that within the Client application. If I need to map a user to a Claim, I can do that on the Client application. I don't need to do this on the Identity Server.
Is this functionality that already exists? If so, what do I need to be looking for? From what I can tell, it appears that the mapping between the User and the Resources they have access to all occur on the Identity Server.
The guide I am following is this: http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html#defining-the-api
Thank you for any guidance.
The Identity claims are not supposed to be used for Authorization, in fact Authentication and Authorization are two totally different concerns.
I'd suggest you watch this video which explains why and also provides an alternative PolicyServer that would answer your questions (great talk from the developers of IdentityServer).
I inherited an existing .net web application. It is an external website that is used by external users and internal users. To login/authenticate internal users, it uses LDAP authentication. External users goes to a different DB.
My IT department wants to change the way internal users login. They do not want to allow an external server to be able to access the AD using LDAP. Is there a more secure method to access the AD from an external server? Or is that not recommended at all?
Also, is the design of the login flawed? Should internal and external users be logging in the same way? What is considered best practice for logging in users?
You could use ADFS (Active Directory Federation Services) for this.
This will require you to install an ADFS server inside of your network (so it can contact the AD).
The ADFS Server contains a web based STS (Security Token Service) to allow web pages to login using an AD account.
Basicly in a nutshell it will work as following:
Your user navigates to the external Web Application
The Web Application will redirect the user to the ADFS STS server.
ADFS STS Server will verify your credentials (either by using integrated security or a web based login box)
If the ADFS STS Server is happy abou the credentials it will then redirect the user back to the external Web Application with a login token as extra information. This token contains information about the user (can be configured). It is signed by the ADFS server (to ensure the information is authentic) and can optionally be encrypted.
The external web application extracts the token and tests the signature. If it is all correct the Web Application will grand the permissions that the user should have.
For information to set this up in an ASP.NET application you could refer to the following url:
http://blogs.msdn.com/b/alextch/archive/2011/06/27/building-a-test-claims-aware-asp-net-application-and-integrating-it-with-adfs-2-0-security-token-service-sts.aspx
I am programming a web application for a company, they require that the user should not enter any username and password, the user should be allowed to login to the system by their windows identity.
i have tried WindowsIdenity.GetCurrent() , its working on if the application is on the client.
How do i get the WindowsIdenitiy of the Client User to be sent to the server.
Internet Explorer has a mechanism for transferring the client's windows credentials to the server. You'll need to make your clients use IE, and of course make sure they are on the same domain forest as the server.
You can read here a little about using integrated windows authentication with ASP.NET .
I'm trying to implement SSO on a windows domain. I already have a service that allows a user to log in via username and password, and this works great. What I'm looking for is a when a user logs into their machine via a domain (controller), what do I need to send the other server to allow it to verify that the user is authenticated against the domain. So what I'm asking is, is there a way to get an authentication hash/key from the user, that can be sent to another server, and that server use it as credentials against the domain?
We have the following setup for authenticating users. A wcf authentication service that is hosted as a windows service on a server machine. The client is a C# CAB based application that communicates with the authentication service and other services (auditing,..) as needed.
We want to give an option of using Active directory to logon to the application.
The steps that were proposed are as shown below.
Authentication service running on server
user opens application on client
machine and chooses login by AD.
application, uses the userName and
password to authenticate user
against AD.
application sends some token from
the authenticated user to the
authentication service, to get back
information about sql server and sql
db name.
authentication service uses token against Active Directory
and verifies that user is logged on
and authenticated and returns back the required sql information.
Are steps 4 & 5 possible without the client app needing to send the username and password to the server for authenticating against AD? I want to avoid as much as possible sending passwords on the network.
You can't do that with AD and a client only, you need to involve a service in the authentication mechanism. If I were you, I'd send the username and password to the authentication service, the client shouldn't talk to the AD directly at all. And if you need some SSO, you can create a token in the authentication service. AD doesn't issue tokens, only you can, or another, more sophisticated service, like ADFS.