This is what I wish to achieve:
My ASP.NET web service is hosted on a server called //service. I want to control access to the web service by server and by application as well. What I mean here is if I have two ASP.NET web applications (app1 and app2) hosted on a server called //web1 and I only want //web1/app1 to be able to call the web service. I know that I can grant access to the IP address of //web1 but that would allow both //web1/app1 and //web1/app2 access to the web service.
I am thinking about using an SSL certificate as I don't want the web application to handle the login/password. on //service, I will grant access to the ip of //web1 and map a client certificate from //web1 to a windows account and this will allow only applications from //web1 to access. But then how do I further control the access to only //web1/app1?
You can use standard HTTP Authentication to control which applications have access to your web service.
Credentials are passed in the Authorization header with each request. Every web service client (i.e. //web1/app1) should have its own credentials, so if //web1/app2 tried to connect to the web service without providing recognized credentials, it would be denied access.
I recommend using SSL to encrypt all traffic, so that authentication information and other sensitive data is secure.
Here are a few articles that may be helpful:
HTTP Security and ASP.NET Web Services (see Authentication section)
Authentication in ASP.NET Web Services
Good luck!
Not really.
A certificate secures the transmission between the client and server domain. It doesn't really work to have multiple certificates for multiple subdirectories.
What you'd want to do is to create a login service that returns a token. You then use that token to manage the session on the server side and the client uses it along with every subsequent request to access and execute the available services. (can this token access this webservice? t/f)
You're going to have to give the client access to some sort of credentials. Whether that is a certificate exchange or a user/pass you're going to have to figure out who the client actually is.
Related
I have an application running on this following structure:
My Actor is PKCE SPA application holding an access token, made with IdentityServer 4 redirection flow. My Frontend website allow this access token. Some of the Frontend website operation is calling the API server logics.
Right now I have an endpoint in the API server that requires the caller to be Frontend website client. But, I also want require a user content, the Actor in this case, which represent the user asking for the server.
Is it possible to supply two access token (one for the OpenId client, other for the customer)? Or I miss a better solution?
I'm trying to get information how to authenticate and authorize a user from a backend WCF service using OpenID Connect configuration rather than using a client application (like Angular / .Net MVC web application).
Can this be achieved using "Authorization Code Flow"?
If yes, could one please guide me, how this can be achieved as we will not be able to configure the re-direction URL for a backend service to get the access token.
If not, could one please tell me how this can be achieved? I did read that this can be achieved by back channel communication (i.e. https://openid.net/specs/openid-connect-backchannel-1_0.html. If one can help me with the tutorial document that is available in internet that would be really helpful.
The link you mention is about back-channel logout: a communication from your OpenID provider toward your backend to notify your backend of a user ending her/his session at the OpenID provider. I do not see how this could be used to authenticate a user.
It feels somewhat odd that you are trying to authenticate a user from a backend service. The whole idea behind OAuth and OpenID is to pass a credential allow with your request to the backend. The backend must verify that credential but should not involve in gathering and issuing that credential, it should rely on a trusted party (the OpenID provider) to issue those credentials.
I have a Web application that uses Google authentication using clientID, secret key and redirectUrl. Now I have another application that is a Windows Form app and want Google authentication using the same clientid as the one used in the Web application. How can I do authentication in the Windows app?
There are several types of clients that you can create for accessing Google's authentication server.
web browser applications
native (other) applications
service accounts
mobile
Each type of client uses a different set of credentials and in some cases a different grant type. For security reasons they are designed for use with the type of client that will be used to access it.
A web browser client is requires a redirect uri so that the authorization server knows were to return the credentials to. A native installed application does not require a redirect uri because the authorization server knows to return the authorization to the same place that the call came from.
Answer: You can't use a web browser client in an installed application. You will need to create a native (other) type of client in your project and use that.
I've got two MVC sites that use the same STS for authentication. I need to create a WCF service as part of one of the sites that allows the other site to retrieve data.
These sites could be on different machines accessible over the internet (although currently they're on the same machine) and the WCF service should only be able to be accessed from the client site. The authentication token used to log into the client site should be passed through to the WCF service.
I've been looking at the different WS-Security options available (Transport, Message etc) and it's not quite sinking in 100%, and I feel like I'd end up implementing something that seemed secure but wasn't actually secure due to a lack of understanding. Any help much appreciated.
Edit:
My first attempt was with transport layer security and setting the WCF service virtual directory with require SSL in IIS. However that left me with an error of:
"The remote certificate is invalid according to the validation procedure."
And I had no way of ensuring that a specific client was connecting to the service, only that a client had a certificate from a trusted CA. At least as far as I know. I'm probably missing something vital here.
The authentication token used to log into the client site should be
passed through to the WCF service.
In this case you should be requesting an "ActAs" token from the STS:
The WCF service should be configured as a Relying Party of the STS.
The MVC site should call back to the STS and request an ActAs token specific to the WCF service.
The MVC site uses the ActAs token to call the service.
The motivation for the complexity: Delegation, or traversing multilayer architectures
Since you mentioned WS standards:
Requesting Delegation (ActAs) Tokens using WSTrustChannel (as opposed to Configuration Madness)
Not knowing your STS its hard to say more, but Googling "ActAs token" will probably give you what you need.
I have Active Directory Federation Services 2.0 all setup and ready to work, but I have a scenario that falls outside pretty much everything I've read on enabling a relying party application. The 2 scenarios that are well documented involve A) Passive authentication for a web site or B) Using a thick client that's authenticated for calling web services.
My scenario is as follows: I have a web application that calls WCF services via Net.TCP for data access. I need to use ADFS 2.0 to secure each WCF call with a secure token.
I also can't use use the passive method of authenticating with ADFS from the web site (security restrictions outside my control).
So my question is, is it possible to manually request a secure token from ADFS via a web site, then use that same token to call my WFC service methods?
Have a look at http://travisspencer.com/blog/2009/03/caching-tokens-to-avoid-calls.html.
In this blog post it is described how to cache security tokens for wcf service calls.
I think it should also be possible to "inject" an already fetched token in the described "CacheSecurityTokenProvider".