I have a question regarding ADFS server. On ADFS server, when you click on endpoints, there are two headings proxy-enabled endpoints and enabled endpoints? I don't understand the difference between the two, can someone please explain what the difference is? I tried looking this up but can't find the difference in detail, just that a proxy enabled endpoint will become available on the internet and for security purposes you don't want to proxy enable all the endpoints? Is that right? But then which endpoints should be proxy enabled and which ones shouldn't, how can we find out?
I am new to learning about ADFS and trying to understand everything. So any help will be much appreciated. Thank you.
End Points are the URL ADFS will post an assertion too.
Proxy Endpoint is the URL Web Application Proxy is configured to use.
Related
I am building Web API with ASP.NET Core hosted on IIS that will act as proxy integrating a few services.
I need to forward user credentials/identity to specific services managed by my API and to do so i want to enable ticket forwarding in Kerberos.
What steps i need to take to make it work?
First of all I need to setup my service as trusted in KDC and after that should it will received forwardable tickets instead of regular ones (i need to specific services that my API can forwards tickets to), am i right?
How do i then forward that ticket to other service using HttpClient?
Does attaching received token to request will be enough?
Am i correct about listed by me steps and is there any thing more to do?
Thank you all for help.
How Firebase domain whitelisting works behind the scene to make it foolproof?
To be clear, I'm not trying to configure my domain in Firebase console(Which I understand how to do), but instead, trying to build some similar source domain validation in my server side - API code. What web standards Firebase uses to make sure only authorized domains make API call as the API token is public.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered. Trying to understand the how its foolproof.
My guess would be that it is not fool-proof, but limits the use cases in certain situations.
You could use such a whitelisted domain in the CORS related headers, this would prevent certain actions from modern browsers.
The whitelisted domains can also used with authentication to make sure the redirect after login is to your domain.
Theoretically you could go and check the Referer header, but a lot of browsers do not supply it for security / privacy purposes so that would be a bad option.
As for firebase, since it is quite hard to use firebase without the library, the library can just supply the current url to the server and prevent any action from unlisted domains. This is by no means fool-proof.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered.
I think your assumption is wrong. Clients are insecure and any request can be faked. Eventually it's a packet that is sent to a server and if you control the sender you control the contents of the packet.
If we monitored the connection between the client and Firebase we can figure out a way to perform the same tasks from another (out of browser) process.
TLS. If you look at the IETF's documentation Handshake Protocol Overview :
When a TLS client and server first start communicating, they agree on
a protocol version, select cryptographic algorithms, optionally
authenticate each other, and use public-key encryption techniques to
generate shared secrets.
So, I think this is the mechanism used for domain whitelisting. Regarding faking HTTP headers, Firebase does not accept HTTP, only HTTPS (TLS).
Is there an efficient way to block REST services to anonymous users?
I am running a website in ASP.NET 4.0 where people log in and according to their credentials they have access to different maps. I would like to avoid having them log in again.
The ESRI WebAdaptor is only running in ASP.NET 2.0 and I'm having a real hard time making it work with the rest of the website. I am not a web guru at all, just inherited this project lucky me.
Thank you for any suggestions or ideas!
Alex,
We had to deal with this issue within our organisation as well. We used an Apache load balancer as a reverse-proxy solution so that only authenticated user's requests to REST services were redirected.
This was the most reasonable solution in our case but you might look into ArcGIS Server token service:
Securing Internet connections to services
Which version of AGS are You using?
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.
I'm going around in circles with regards to WCF and security so i'm just going to shove a load of questions here and hope someone can help me gain a clear picture.
Can someone please give me a plain English explanation of Transport vs Message level security.
I think I have a service running under SSL that will authenticate the user based upon their windows credentials. I also think I understand how to limit access to a service method via the PrincipalPermission. But how do I actually retrieve the current IPrinciple, so I can return different results dependent upon who's calling the service?
I have figured out how to turn tracing on and I can see my trace logs using "Microsoft Service Trace Log Viewer" but ill be damned if I can figure out what Im being displayed. Is there a decent resource explaining how to use this thing?
When using the "Certificate" clientCredentialType, is this somehting different to SSL?
When using the "Windows" clientCredentialType how can I see what windows user is being passed through?
My requirements mean I have to use basicHttpBindings - Am I correct in assuming:
I only have Transport level security available to me?
I can not implement custom username/password for this binding?
I know these questions may seem stupid, but any help with clarification would really help.
EDIT:
How can I add custom SOAP headers to my service in a similar manor to .asmx services? Is this a valid approach?
EDIT:
Further to the above questions I would like to know if it is possible to authenticate a windows mobile device based upon its windows user by checking against Active Directory. For all that I have found so far it seems unlikely.
N.B. For those who do not know whats available for windows CE's version of WCF its: Transport level security only, and either none/certificate for the Client Credential Type. So it seems that CE's WCF wont allow this by default but could I securely send this information in the message (via the method signature) and would this be an acceptable way of sending this kind of information?
I don't know all answers but here are the ones I do know
transport security means the communication is encrypted while the message is transported so it can't be read and or tampered with. Message security means the contents of the message itself is encrypted the transport however isn't necessarily. Message security can for instance be used with HTTP while transport security would require the use of HTTPS (or other bindings).
IPrincipal principal = Thread.CurrentPrincipal;
no answer
Yes, although SSL itself uses certificates it's not the same. You can have the client send a certificate which is known to the service or which is signed by a trusted authority to that the service knows who the client is and whether to allow them to make the call or not. Using SSL will only ensure that third parties can't read the communication between the client and the services by intercepting the network packages.
IPrincipal principal = Thread.CurrentPrincipal; principal.Identity.Name;
No.
You have None, Transport, Message and Mixed security as your options however Transport security will require calling the endpoint using HTTPS since thats the secured version of the protocol
EDIT: Check out the discussion at this forum.
And the questions certainly aren't stupid.
P.S. I can recommend the book programming WCF services by Juval Lowy it's really in depth and comes with a really useful framework extending WCF/Simplifying certain things.
Check out WCF Security Guidance. If you need more information, you should be able to find it all there, its quite complete. Though it looks like #olle gave a pretty complete answer....
Also check these WCF Common Security Scenarios