Just some feedback, I found the audio in the video explainer hard to follow. It sounded sort of weirdly text to speech and/or there were grammar mistakes in the original transcript. I'd get a professional to rerecord it.
Yes, it's based on Microsoft Neural speech [0]. We made it in quick turn-around, with frequent changes, so thought of doing it first with Neural speech. Can definitely switch to a real human speech now as the content is relatively stable (though we're working for a client on an attribute-based authorization policies, extending ADA with that, so more changes will come to the first video!)
Glad you asked! I'd incurrage to go through this [0] guide, or watch [1] video. But briefly: ASP.NET Core policy authorization works on full trust mode when it comes to the data sent by the callers. This means unless you write code to authorize access to resources, users will have access to everything. And to authorize a single resource mentioned in an API operation, you have to write lot of code including a requirement definition, an authorization handler, and invocation of the authorizationService from the action body. Just imagine doing this for multiple resources in an operation and doing it for hundreds of API operations. All this is hard-coded which is vulnerable to omission and manual mistakes, not to mention the time you spend on writing/maintaining such code.
On the other hand, ASPSecurityKit works on zero-trust principle, which means by default users have access to nothing, and gain access to only those resources you explicitly grant. The best part is that you don't have to write any code for this protection in most cases; your code remains crisp and clean throughout.
> The zero-trust security model assumes breach as the default phenomenon and therefore, it advocates verifying every request with all possible options available to ensure the legitimacy of the request. It also emphasizes following the principle of least privilege access to limit access to the system for only the functions requested even though the elevated privilege might be available for the caller.
> Zero-trust and least privilege access are fundemental principles to ASPSecurityKit design. Few examples:
> 1. As you apply ASPSecurityKit’s ProtectAttribute on the base controller (or the base service in ServiceStack) or as a global filter, it instantly begins guarding all operations of your web application with a multi-stage security pipeline that involves, among other things, XSS validation, authentication, multi-factor, authorization. All these checks are necessary unless you disable one or more for specific operations.
> 2. Following the same principles, activity-based, data-aware authorization components enforce that to execute an operation, the caller must possess its corresponding permissionCode, and any existing data being referred for the operation must also have been permitted. You can selectively exclude operations and data from these checks, but the default is to guard everything.
The user verification, user suspension and entity suspension checks are designed to block every incoming requests if the corresponding check fails, and give you tools and control to explicitly exclude certain operations (of your choice) from the check.
Very pertinent question. with ASPSecurityKit, you get the whole auth/user management stack right as part of your application while with AuthZero, it's offered as a service. Your cost and risk will increase with such SaaS services as your product and number of its users grow while with ASK, the cost remains stable, and without risk of third-party exposure. IMO, user management is so core to any web application that it's not worth it to outsource it if you have a long-term plan for the product.
Additionally, even if you're using an auth service, the automatic data authorization feature that ASK provides through its ADA feature [0] and [1], is something you've to still build in your app, as authorization of input data depends on the domain model of your application and not something generic like user model. ASK can make it automatic because it lets you define convention once (and comes with default conventions based on best practices btw), and takes care of applying them throughout your requests, obviously working with you wherever you need to override something.
Yes you can integrate with any provider. the pipeline [0] is the enforcement part – performing MFA checks like "Is MFA enabled on user? is it applicable for this request (can be turned off for programmatic api-based access, for example) etc."
It's the job of the application to prompt caller for 2FA input and verify it using the provider/device of your choice.
But to save you time even with that implementation, ASPSecurityKit has a category of products called source packages, which provide full implementation of several commonly needed functionality, including 2FA workflow [1], installed right into your project as source code, so you can switch to any MFA provider easily by modifying the code that sends MFA token to the device.
https://aspsecuritykit.net/features/#mfa, ASPSecurityKit mentions it can integrate with different token providers and Saas Pass has custom integration via API as well
There's good and bad apps, like most platforms, and it is comparable to PHP from that perspective. Having worked extensively in both, I'd say the general problem with PHP is it's really easy for a beginner to get started, and just easy to grow a small, simple app into a large, functional-but-awful monstrosity.
ASP.NET is really just a foundation layer for a whole bunch of different web frameworks including WebAPI, MVC, RazorPages, Blazor, WCF and WebForms. I'd blame WebForms in particular for a lot of the bad apps: it basically tries to make the web act like stateful Windows Forms apps (literally with controls that have "server-side events" and maintain state across several HTTP requests). As a result, lots of Windows Forms developers could build apps without actually understanding a lot of the complexity of the web and especially its security implications.
Not sure what was the particular issue you faced, but ASP.NET Core has come a long way – you can run .NET Core apps on Linux as well, not to mention the whole thing is open source under DotNet Foundation [0].
[+] [-] martinald|5 years ago|reply
Looks interesting though.
[+] [-] TriNetra|5 years ago|reply
0: https://docs.microsoft.com/en-us/azure/cognitive-services/sp...
[+] [-] abgr-y|5 years ago|reply
[+] [-] TriNetra|5 years ago|reply
On the other hand, ASPSecurityKit works on zero-trust principle, which means by default users have access to nothing, and gain access to only those resources you explicitly grant. The best part is that you don't have to write any code for this protection in most cases; your code remains crisp and clean throughout.
0: https://aspsecuritykit.net/guides/aspnet-policy-authorizatio...
1: https://youtu.be/t-3bhDKJvlY
[+] [-] kr4|5 years ago|reply
[+] [-] TriNetra|5 years ago|reply
> The zero-trust security model assumes breach as the default phenomenon and therefore, it advocates verifying every request with all possible options available to ensure the legitimacy of the request. It also emphasizes following the principle of least privilege access to limit access to the system for only the functions requested even though the elevated privilege might be available for the caller.
> Zero-trust and least privilege access are fundemental principles to ASPSecurityKit design. Few examples:
> 1. As you apply ASPSecurityKit’s ProtectAttribute on the base controller (or the base service in ServiceStack) or as a global filter, it instantly begins guarding all operations of your web application with a multi-stage security pipeline that involves, among other things, XSS validation, authentication, multi-factor, authorization. All these checks are necessary unless you disable one or more for specific operations.
> 2. Following the same principles, activity-based, data-aware authorization components enforce that to execute an operation, the caller must possess its corresponding permissionCode, and any existing data being referred for the operation must also have been permitted. You can selectively exclude operations and data from these checks, but the default is to guard everything. The user verification, user suspension and entity suspension checks are designed to block every incoming requests if the corresponding check fails, and give you tools and control to explicitly exclude certain operations (of your choice) from the check.
...
https://aspsecuritykit.net/docs/article/introduction/#zero-t...
[+] [-] sbehlasp|5 years ago|reply
[+] [-] TriNetra|5 years ago|reply
Additionally, even if you're using an auth service, the automatic data authorization feature that ASK provides through its ADA feature [0] and [1], is something you've to still build in your app, as authorization of input data depends on the domain model of your application and not something generic like user model. ASK can make it automatic because it lets you define convention once (and comes with default conventions based on best practices btw), and takes care of applying them throughout your requests, obviously working with you wherever you need to override something.
0: data authorization in design guide https://aspsecuritykit.net/guides/designing-activity-based-d...
1: data authorization in implementation guide: https://aspsecuritykit.net/docs/article/how-to-perform-activ...
[+] [-] TriNetra|5 years ago|reply
[+] [-] 1cvmask|5 years ago|reply
[+] [-] TriNetra|5 years ago|reply
It's the job of the application to prompt caller for 2FA input and verify it using the provider/device of your choice.
But to save you time even with that implementation, ASPSecurityKit has a category of products called source packages, which provide full implementation of several commonly needed functionality, including 2FA workflow [1], installed right into your project as source code, so you can switch to any MFA provider easily by modifying the code that sends MFA token to the device.
0: https://aspsecuritykit.net/docs/article/the-security-pipelin...
1: https://aspsecuritykit.net/docs/article/source-packages/?pac...
[+] [-] abgr-y|5 years ago|reply
[+] [-] fm200|5 years ago|reply
Jokes aside, i dont know that much how is it today, but years ago i had to run some asp.net apps in production, it was a nightmare...
[+] [-] gregmac|5 years ago|reply
ASP.NET is really just a foundation layer for a whole bunch of different web frameworks including WebAPI, MVC, RazorPages, Blazor, WCF and WebForms. I'd blame WebForms in particular for a lot of the bad apps: it basically tries to make the web act like stateful Windows Forms apps (literally with controls that have "server-side events" and maintain state across several HTTP requests). As a result, lots of Windows Forms developers could build apps without actually understanding a lot of the complexity of the web and especially its security implications.
[+] [-] TriNetra|5 years ago|reply
0: https://dotnetfoundation.org/