Can we have more than one authentication (anonymous, windows, forms, basic, etc) enabled in IIS at a time?
If two or more authentiation are enabled, what is the order by which authentications are handled?
And, if there is an order, how to change it?
Negative.
If you had Basic + Anonymous enabled, Basic would take priority, and Anonymous would never be used if they failed Basic... understand?
"An important restriction that you should be aware of when enabling different authentication methods is that you can’t enable both a challenge-based and a logon redirection–based authentication method at the same time. In other words, you can’t enable forms authentication (which is redirection-based) while basic, digest, or Windows authentication (which are challenge-based) is also enabled."
http://windowsitpro.com/systems-management/understanding-iis-70-authentication <-- Good read
http://www.iis.net/configreference/system.webserver/security/authentication#005
Related
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
We are using WCF services. Right now, we are using Windows Auth but this is not for long. Some services will sit outside the firewall and use username/password verified in the database.
My tech lead is "scared" at how easy any user can "Add Reference" to the services we have and just party on. He wants to "guard" the services by adding another identity - the application. He wants the service to accept requests from certain applications so the certain users cannot just use the service - add reference to it and call. It’s the notion of the application having an identity + credentials that is the operative principle here, as services on the network may need to authenticate those credentials prior to fulfilling a request, in order to prevent rogue code inside the network (i.e., NOT the application) from accessing services using “Joe User” end-user credentials.
Does this make any sense?
Then he believes the Juval Lowy's book has, in an Appendix that discusses sending more than one identity during a WCF call (Security Interceptor). There is no specific suggestion that all of those have to be end-user identities and if that is the case, one of those could be the identity of the application making the request.
How can this be done?
Thanks,
Sam
The problem with sending an application identity is that the secret used to confirm that identity has to be stored somewhere. If it is visible to one application on a machine then generally it will be visible to other applications running under the same identity.
Would your manager be happy with "it came from an authorised machine"? If that's the case you could simply use Client Certs
Its also worth taking a step back: if the user is authenticated and is authorized to perform the functionality they have requested, why do you care which application they came from - if they are who they say they are and they are allowed to do what they are requesting then why couldn't they use, say, fiddler to make the request - isn't that the point of a service (rather than a closely coupled client server app)?
You might want to look through Common Security Scenarios in the MSDN documentation to see if any of those options fit your needs.
The options that pops to my eye are Transport Security with Certificate Authentication and Message Security with Mutual Certificates. Both rely on X.509 certificates. The latter option is on the message level, so you can handle certificate delivery and security negotiation however you want.
To make it a lot harder for someone to add a reference to your service you could just remove the mex endpoint. This way it would be very difficult for a stranger to create a valid request message.
You can then distribute the WSDL manually, only to people you trust.
(I tried searching, but couldn't find any truly helpful links.)
We are implementing a set of WCF services. What I would like to do in these services is have the clients (which will be trusted application servers) be able to pass a token of some sort to the web service to authenticate. I do not want to be required to pass username/password on the initial or subsequent requests (because in some cases the calling application server may not have the password). Windows and Kerberos are not usable in our specific circumstance.
I had thought to just create a simple custom UserNameSecurityTokenAuthenticator class and modify it so that if the password is empty, it takes userName as the string-encoded token value (obviously checking the token itself to verify that it's valid at that point), but if the password is not empty, forwarding on the username/password to a MembershipProvider for checking. Basically I'd like to overload the username/password authentication to provide for token passing as well.
Is this possible? Can I simply plug in a token authenticator like this, or is there some other simple way to "intercept" requests like this (and update the actual username value from the decrypted token)?
Or is there some other incredibly simple way to allow the client to pass a custom token and have the server accept it that I'm just missing?
If it's a fairly controlled environment and not too many clients involved, then I'd try to set up something along the lines of the B2B scenario securing the transport link using certificates on both ends.
Certificates are not bound to Windows or an AD domain, and setting them up is a one-time job.
Read more about that WCF security scenario:
MSDN: Transport Security with Certificate Authentication
Fundamentals of WCF Security: Business Partner Applications
. WCF Security How-To's
I'm trying to understand how windows authentication / encryption works with the NetTcpBinding in WCF. I need to know exactly what encryption algorithm is used to encrypt the data going across the wire (and some documentation to prove it). Will windows authentication / encryption still work if the client and or host is not on a domain?
The netTcpBinding using Windows Credentials requires the caller and the service to be on the same domain - or at least on mutually trusting domains. Otherwise, the server won't be able to verify the Windows credentials and will refuse the service call.
As for encryption : you can even pick and choose which one you'd like ! :-) TripleDES, AES - you name it, with varying key lengths, too.
See the Fundamentals of WCF Security article - it talks about all aspects of security and encryption; also see the MSDN Docs on Securing Services which goes into some more detail; a good overview can be found here showing the properties of the basicHttp transport security element.
Last year I had to implement a distributed system using wcf that required a mechanism both safe and performant across all layers of the system. We decided for creating our own security architecture by creating a binary encrypted token. The encrypted token contained all permissions a given user had.
So for example a user would log in into the system and if successfully authenticated it would receive an encrypted token back. This token was stored locally on the web client. All further requests by the user would contain that token. The token was used in several levels of the architecture. The web server would use it to decide what visual elements to enable or disable. Since the service layer was exposed to the internet, each open door would check the token for authentication and check if that token had the proper permission to execute a given task. The business layer could check again for a more specific right included in the token.
The advantages:
It didn't matter if we were using NetTcpBinding or any other type of binding (and we did use more than one type of binding).
We saved a lot of round trips to the database
We could use the same token on different platforms
I know it probably doesn't answer your specific questions, but it will maybe give you some for food for thought while you're still deciding on the intra-layer architecture of your system.
Sorry if the spelling is completely wrong. What the heck is one? Why is it preventing me from authenticating via Mozilla? Why would someone force me to use one to authenticate from a command line tool? How is it tied to the back end being implemented in Silverlight?
SPNEGO Simple and Protected GSSAPI Negotiation Mechanism is a GSSAPI "pseudo mechanism" that is used to negotiate one of a number of possible real mechanisms.
SPNEGO's most visible use is in Microsoft's "HTTP Negotiate" authentication extension. It was first implemented in Internet Explorer 5.01 and IIS 5.0 and provided single sign-on capability later marketed as Integrated Windows Authentication. The negotiable sub-mechanisms included NTLM and Kerberos, both used in Active Directory.