It's really strange question, but...
So, does any pure internal IdentityServer4 analogues in ASP.NET Core exist?
I have some Web Services via WebAPI. These services are strongly independent, but I want to restrict an access for part of it (I want to use JWTs).
I want to have one certification authority for all my apis, which could use ASP.NET Core Identity, of course, and grants of denys an access for specific api.
I don't want to use IdentityServer4 right now - maybe it's possible to solve this problem through an internal resourses of ASP.NET Core.
Thnxs.
Yes, ASP.NET Core provides out of the box tools for authentications and JWTs.
You will need to configure your Startup class and add the approperiate services/middlware.
Here's an article to get you started:
https://developer.okta.com/blog/2018/03/23/token-authentication-aspnetcore-complete-guide
If I'm not mistaken, IdentityServer actually wraps around these tools under the hood.
Related
I have two applications, one in asp.net and the other in asp.net core. I want to share a common database, as well as the same login. Ie, a user can register via asp.net application, and then their identity will be shared with asp.net core application.
Is this possible? I notice that each have their own identity models, and I am looking for a way of sharing this, ie. some documentation to resolve this.
Looking for:
- Is this possible?
- Documentation and more information on implementation (how to)
I am resolving by use of Identity Server, which both applications will hook into. Will just take a bit of re-jigging.
I'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
We have an ASP.Net C# application that requires some form of a web services implementation for integration with other applications. Currently we have been looking at servicestack and also using an ESB e.g. Mule.
I am trying to figure out the best way to integrate an ESB like Mule into our ASP.Net application.
Do we need to build a web service into our ASP.Net application so that an ESB can integrate with it?
If yes what would be a good approach for selecting a web service type (e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an ASP.Net application and Mule?
Do we need to build a web service into our ASP.Net application so that
an ESB can integrate with it?
Usually it's the other way around. An integration middleware, like Mule, speaks tons of protocols just for the sake of being able to connect to existing systems without changing them.
If yes what would be a good approach for selecting a web service type
(e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an
ASP.Net application and Mule?
If your application has really no pre-existing channel you could use to integrate with (not even a simple web form HTTP POST? really?) and you want to expose an API so an integration middleware can connect to it, pick the architecture/technology that maps to the API style you're creating (REST for a resource oriented API, SOAP for a RPC oriented API).
This sounds backwards. What are you required to integrate with, and what capabilities are you trying to provide?
A web service is decoupled from its implementation, you would choose to use a web service if you're trying to expose your system capabilities in an interoperable way so that it's accessible by a broad range of clients.
What you do within a web service is up to you, i.e. you could then for example connect with your ESB. Nothing is precludes you from doing that. ServiceStack also supports hosting from within an existing ASP.NET (or MVC application) see the Hello World example for different ways of configuring ServiceStack.
REST / RPC has to do with the design of your web services and ServiceStack supports both models. i.e. inherit from RestServiceBase if you want to provide different implementations when the service is invoked with different HTTP Verbs. Inherit ServiceBase if you want the same implementation to be used no matter how it was invoked. This article shows the difference between REST vs RPC/SOAP - and how you can support both in ServiceStack.
So if your exposing a single operation (or want to support SOAP) use ServiceBase, if your exposing a 'Resource' where you want to allow it to be managed using different HTTP Verbs use RestServiceBase.
I'm currently working on an application that will likely be deployed amongst various organizations within my current workplace. I need to develop a testable and properly designed authentication framework so that for each implementation folks can choose to use either Windows Authentication, Forms Authentication, a home-grown Single-SignOn system OR OpenID.
So given ASP.NET MVC (and in particular I'm using the S#arp Architecture framework) how should I go about doing this?
Ideally it would be nice if folks can simply make changes to the web.config file in each case.
Thanks
ASP .NET MVC supports ASP .NET membership provider, making it easier for you to handle Windows/Forms Authentication without any hassle. As long as you specify the required information on the web.config. The default site comes with an example.
For other options of implementation, Kigg has an OpenID implementation which also includes the unit testing code.
I guess that after learning how those work you'll find a way to include your "home-grown Single-SignOn" authentication framework :P
Update:
In order to use the membership provider using your own users table, you must implement a custom provider. The configuration through the web.config will be available anyways, but you'll need to create a class which implements the MembershipProvider abstract class.
Here's a link to a video and some source code explaining how to achieve this.
I've just been tasked with building a web application using ASP (.net) and am looking for some advice on where to start. In a nutshell the application needs to be able to.
Handle user verification / authentication
Handle sessions
Do SOAP messaging
The application is intended to act as a front end for system functions that are accessible via web service calls.
I intend to do a lot of work on the client side using JavaScript and am thinking of using ASP solely as the framework for the 3 items I listed above.
Appreciate any suggestions you may have.
Use Visual Studio 2008 if you can. Its support for Ajax client libraries and javascript intellisense is very good. (Check out the jQuery add in)
ASP.NET has built in Login controls (and the membership services mentioned by ChrisE), and also has Forms Authentication. Try to leverage these existing components and avoid using session to store user specific objects/data.
---session rant
Its sometimes unavoidable, but you should avoid it whenever you can. It incurs a burden on the webserver for each user, and that leads to some very difficult scaling problems. The FormsAuthentication Ticket has a value property that you can store about 4K worth of user data in - try to use that instead.
---End session rant
Try to use a MVC approach (not necessarily an ASP.NET MVC), but at least one that seperates your presentation / view layer from the data / model layer.
Create a default theme and use it. Most sites will need to have multiple themes later, and refactoring that will be a PIA.
If you need SOAP to interact with Non-.NET services then by all means use it. If you are only connecting to .NET services then look into WCF clients and services. They will give you more flexibility.
If you are doing the client work in javascript, then dont use the update panel. It adds lots of overhead.
Get FireFox + FireBug + YSlow, and IE8 (yeah its beta still). They will help you when dealing with the client end of debugging / styling.
Take a look at the rules for website performance, but take these with a grain of salt. They are intended for very large sites, and some of the items may not be applicable (CDN, DNS lookups, Redirects).
WCF for Soap -- I would also suggest picking this up:
alt ASP.NET 3.5 http://ecx.images-amazon.com/images/I/518N8vYWf1L._SL500_AA240_.jpg
This book is in tutorial form -- and Jesse Liberty is a great teacher (as are his co-authors).
ASP.NET provides out of the box authentication/authorization through the SqlMembershipProvider and SqlRoleProvider classes, or you can use the ADMembershipProvider along with a custom RoleProvider to authenticate and authorize against an Active Directory setup.
Session handling is readily provided by ASP.NET as well, through an in-process server, an external StateServer service, or through a connection to SQL Server (and of course, you can provide a custom Session service if you need something different).
As Lou Franco mentioned, WCF provides the framework for the SOAP calls, and will blend in with your ASP.NET application quite handily.
If you are using ASP.NET Web Forms then for handling user authentication/verification I'd recommend ASP.NET Membership services http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx because it does some of the heavy lifting for you and also helps you from making any elementary security mistakes.
This is not directly related to your requirements, but I'd suggest you study the differences between Web Site and Web Application. The sooner the better. Everything will go smoother if you understand how the project is managed.
You can start here: http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx