I am looking for best practices around security configuration management in web application during development. I have 2 situations.
I have a bunch of functions (say REST APIs) that returns some data from the database. In production, the calling client will have to authenticate itself say against a AspNetMembership provider.
There is another set of functions where in the authenticated principal information is required to fetch the data.
During development the developer needs to setup security and https in IIS to make this happen. Is there best practices followed in Asp.Net or in other programming languages to disable security during development so that the developer does not have to setup security in local IIS server (not Cassini) where the application is hosted and also not supply credentials in header when debugging.
The best practices would be not to allow security to be disabled. If you're using Forms Authentication, security shouldn't need to be set up in IIS, just in the application, and Visual Studio easily lets you add a development certificate to enable HTTPS.
One last best practice: Use ASP.NET Identity, not AspNetMembership for your identity provider. AspNetMembership is legacy at this point, and does not follow modern security best practices.
Related
We have 2 web applications in production since several years. They are currently only accessible from the intranet of the company. Future changes in the company's organization require to make these applications accessible from the internet. It is planned to use Okta to reinforce security. I don't know nothing about Okta yet. As far as possible, the changes should have as little impact as possible.
Current situation:
Web App 1:
ASP.NET MVC solution secured with userid/password ASP.NET Membership with forms authentication. Userid is an internal user code like ADE465 for example.
Web App 2:
ASP.NET MVC solution secured with userid/password authentication through IdentityServer2 (Thinktecture). Userid is firstname dot lastname like john.doe for example.
All web apps are hosted on IIS on an Azure virtual machine named (let's say) FABVM03.
For the future Okta integration: no need to have SSO (Single Sign On). Would it be possible to simply secure with Okta everything accessed on the server FABVM03? Or everything accessed from a specific URL ?
For example, if someone tries to access https://example.com/webapp1/login.html Okta should comes up and ask for authentication (Okta verify) and if successful allow the user to access the requested url. In fact, the 'already in place' login/password should then be asked as it is already the case. I agree the user would have to enter credentials 2 times: first for Okta verify, next for login the specific web application. But that's okay. As you will have understood, no code modification in the web apps would be necessary in this scenario.
My question is to know if something like that is possible with Okta. If not what is the less impacting possible solution with Okta ?
Okta is not to enforce your policies (PEP), it's mainly SSO and Access Management solution.
Okta has a component, called OAG (Okta Access Gateway), which can be used to reverse-proxy your on-prem applications (which will work in your situation too, as your VPC is effectively equal to "on-prem in a cloud"). Which can do something like you want (protect your application and ask for authentication/authorization), but it's an additional package on top of basic Okta costs.
What you may need is a level of protection added on Azure Network layer, not sure if there is something like that though. I've seen some modules for nginx, capable of intercepting traffic and redirecting it to Okta, if not accompanied with a token. So try to dig into these 2 directions...
You need some proxy-based solution to talk to Okta and enforce the protection for your applications. There are open source tools:
https://github.com/vouch/vouch-proxy
https://github.com/oauth2-proxy/oauth2-proxy
https://github.com/buzzfeed/sso
Or you can checkout some commercial tools:
https://www.okta.com/products/access-gateway/
https://www.datawiza.com/platform/
Can someone explain to me how to achieve single-sign on? I have an MVC ASP.NET core web app(let's say www.internalsite.com), how can the app get the user credentials automatically and authenticate etc.? I need a very clear explanation on how to do it.
By using www.internalsite.com I guess you are talking about a site on an intranet, right? How are you hosted? IIS in front of Kestrel? If so, then it's quite straightforward, you just need to configure IIS to foward the Windows identity (coming from a Kerberos token usually) by setting the proper value in the web.config: forwardWindowsAuthToken="true" as explained here: Asp.net Core Web API - Current user & Windows Authentication and make sure you have a controller/action protected by an [Authorize] tag so that the IIS middleware is challenged and set the identity of the request as explained here: NTLM authentication on specific route in ASP.NET Core No much code to write in your project. If you are using another hosting setup, WebListener, it is pretty much the same.
Another solution, would be to do SSO by client certificate which has the advantage of working cross domain, but SSO by Kerberos is by far easier and usually doing a good job on an intranet.
I'd like to implement a Single Sign-on (SSO) authentication layer in my Spring-based application with the aim of supporting authentication and authorization from different security domains.
I've chosen Shibboleth as IdP, but I have yet to identify what I will use for the SP.
The choices are:
Spring Security SAML Extension: component enables both new and existing applications to act as a Service Provider in federations based on SAML 2.0 protocol and enable Web Single Sign-On. Spring Security Extension allows seamless combination of SAML 2.0 and other authentication and federation mechanisms in a single application. All products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS 2.0, Shibboleth, OpenAM/OpenSSO, RM5 IdM or Ping Federate) can be used to connect with Spring Security SAML Extension.
Shibboleth (also as SP): Shibboleth is a web-based technology that implements the HTTP/POST, artifact, and attribute push profiles of SAML, including both Identity Provider (IdP) and Service Provider (SP) components.
So, I've some questions:
Is it a good idea to use directly Spring SAML as SP in terms of
scalability and maintainability?
It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever (JBoss 8.0 - WildFly)?
Where do I define the roles (for each scenario)?
Which is the worthwhile choice?
Best regards, V.
The main difference between the two is deployment scenario:
Shibboleth SP plugins are deployed directly to the Apache/IIS web server.
Spring SAML is embedded in your application.
Both have pros and cons.
Is it a good idea to use directly Spring SAML as SP in terms of scalability and maintainability?
Spring SAML
Offers great control over how authentication is performed and how the authentication process interacts with your application. You can e.g. create your own configuration UIs and dynamically add IDPs, create custom login screens as part of your application, have complete and easy control over error handling, easily support multiple IDPs, dynamically configured details of the SSO (requested AuthnContexts, NameIDs, bindings, authentication forcing).
Easily parse received SAML attributes in various formats, support multiple authentication methods in the same application.
Dynamically generate SP metadata, it provides limited multi-tenancy and supports profiles not available in all other options (e.g. Single Logout, Holder of Key, IDP Discovery).
Seamlessly interacts with Spring Security which brings a set of benefits of its own. With Spring SAML you can also configure complete authentication and authorization policy directly in your application (e.g. which pages require authentication or not and when, role based access control to content, authentication step-up on dynamic conditions, ...).
Allows you to deploy the application on any application server or container and behind any reverse proxy or web server with no affect on functionality.
Shibboleth plugins
These are statically configured and typically interact with your application through HTTP headers. They decouple authentication logic from the application itself, so the only thing you need to take care of is acceptance of the headers and initialization of your application session with correct security context. The definition of which pages are secured is present on the IIS/Apache server and based on URL patterns which means that authentication and authorization policy is partly defined outside of your application.
You need to make sure that the application can only be accessed through the web server (= prohibit all direct access) as that would allow forging of the headers.
Doesn't require many changes to the application itself and can therefore typically be easily used with legacy systems.
It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever
(JBoss 8.0 - WildFly)?
Yes, it is possible, but it will require effort. You could e.g. configure WildFly to set a shared domain cookie in encrypted format and verify the cookie in your Spring Security configuration.
Where do I define the roles (for each scenario)?
With Spring SAML you define roles when processing the SAML Response by e.g. parsing of the SAML attributes. This is done by implementing SAMLUserDetailsService interface and plugging in to the samlAuthenticationProvider.
With Shibboleth you can forward attributes received from IDP to your application with headers and parse them in your application.
WildFly (probably) allows you to define security context and roles directly in SP with no need to configure this in your application. Such configuration might not be portable across application servers.
Which is the worthwhile choice?
All options will enable you to perform WebSSO with SAML 2.0. People typically choose based on their requirements (e.g. customization needs), environment (used web server, application server), preferred development methodology (Java, .NET, other), used frameworks, legacy code. Both Spring SAML and Shibboleth plugins are used by many customers.
Recently I have been using IIS Express and it works really great. However, I have on scenario I am unable to solve.
I am developing a webapp where users should be able to login with their AD account. Since the server which will run the webapp is outside the domain I use ADFS 2.0 as a SSO solution to solve this problem.
To make development for this project easier, I have chosen to use IIS Express when developing.
To be able to exchange claims information with the ADFS 2.0 server from my development environment, I have to configure the application pool for the site to have Load User Profile set to true (like i.e. IIS 7.5). I have searched around the web, and have so far found very little documentation on how to configure application pools in IIS Express.
This has nothing to do with ADFS but it's the way WIF uses to sign and encrypt the cookie that will be used to identify the user after the initial sign in. The default implementation in WIF uses DPAPI which relies om the user profile to get key material.
You can override that default and use the machinekey as key material instead. Indeed thats the way it works in NET 4.5 by default precisely because all the issues with DPAPI. Here you have the way to do it in Net 4
http://leastprivilege.com/2012/07/12/machinekey-based-session-protection-for-wif/
I am starting a new product that will require a .NET based server (using WCF) hosted on Azure. I would like to have basic authentication and security features. The clients are all "rich" UI but are not neccessarily microsoft ones.
We intend to have the first client application written in Silverlight, but we want to keep our options open to implement clients for iOS and Android in the future. So we do not want to use WCF specific features but rather protocols that are easily available on other enviroments.
Of course, with the Silverlight client, we hope to get as much done for us automatically as possible. We intend to only communicate through web services.
Which bindings are recommended for such a scenario?
How would you implement security? (assuming we need basic security - Users being able to log in with encrypted user and password and perhaps some built in basic role management althouh this is optional).
Suggestions?
You could use WCF to implement a REST interface
The binding would have to be a basicHttpBinding (to be open to all platforms) and using SSL to secure the line.
Managing credentials could be done using tokens to be passed back and forth after authentication. Much like a http session. You could pass the token using a cookie but the token could be part of the API or Headers as well. See this Best Practices for securing a REST API / web service
This would grant you the power of .NET and WCF without losing interopability.