I'm using Linkedin SSO on my website for more than a year now it has always performed as ask, until today. My website is an ASP.NET MVC5 website (C#). I use the classic Oauth2 integration and everything was working fine until yesterday when I changed the domain of my website. I changed in the developer interface the redirect urls (or should I say I added new url redirects) by it always sends access_denied to my callback url and I don't understand why. Has anyone the same issue these days or tips on how I can correct that issue.
Thanks a lot for your help
We had the same issue and after a bit of digging it appears that LinkedIn is now forcing tls1.2 - if you are on an old framework - you may have to upgrade - 4.6+ has tls1.2 as default and should work with no extra setup (although depending on the server you're running on you may still need to set up support for TLS 1.2 - follow the instructions in the top answer on this post : .Net Framework 4.6.1 not defaulting to TLS 1.2) .
If you are on 4.5+ you can just tell your code to use Tls1.2 by adding the following command somewhere global (for example when you initialize linkedin auth):
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Some further info about Tls1.2 and support in .net can be found here : https://blogs.perficient.com/2016/04/28/tsl-1-2-and-net-support/
Hope this all helps!
Related
I was recently handed over the support of an already built logic app that accepts some json and performs some validations and send it to some endpoint. There's nothing wrong with the Logic app functionality, it works completely fine.
The problem is, penetration testing was done on the app and it presented us with security concern of X-aspnet-Version:4.0.30319.
I found this post here and it says:
That is not the actual .NET framework version. It is the version of
the CLR
My questions are, can the above quote be considered as the valid reference to address the issue? If not, can the logic app be somehow upgraded to use aspnet version 4.5 or higher?
And if I can change the version, can this have impacts on my current logic app's behavior?
Note: The app was made entirely through logic app designer and not a
single chunk of coding was implemented
No, the problem is with the test tool, not Logic Apps.
Just because it infers a problem doesn't mean there is a problem.
Explain to you 'security' testers that this is an Azure Logic App, not Windows/IIS. If you tell us the exact 'security concern' we can explain why it's irrelevant.
X-AspNet-Version: specifies the version of ASP.NET being used. Note that this value returns the core framework version. Typical examples include 1.1.4322, 2.0.50727 and 4.0.30319.
ASP.NET web sites send the ASP.NET version information in the web server HTTP Response Header as X-AspNet-Version value automatically to the client. So, you could not change it in logic app.
We are using the code below to send the custom message from server side to client side in HTTP request. It is working properly in .NET Core 2.0
Response.HttpContext.Features.Get<IHttpResponseFeature>().ReasonPhrase
While using the same code in .NET Core 2.1 it does not work. It doesn't throw any script errors but we couldn't get message in client side success.
How to resolve this problem?
I hope it answers your question:
This is not caused by any code changes in the framework, it's caused
by a project configuration change.
The 2.0 project templates did not have HTTPS enabled by default, the
2.1 templates do. When using HTTP the browser uses HTTP/1.1 and ReasonPhrase works as expected. When using HTTPS the browser uses
HTTP/2 and ReasonPhrase no longer works.
Full answer by Chris Ross here.
I'm having issues with a SignalR project I'm currently working on. I'm trying to build a server using .Net Core, and a client using traditional .Net (framework 4.6.1). However the server and client don't seem to be compatible.
The last issue I've run into is a StatusCode: 405, ReasonPhrase: 'Method Not Allowed'. I found an answer on GitHub that states that there are many breaking changes between versions.
Looking at the NuGet package versions available, I get even more confused. for the .Net Core server I'm using 1.0.0-preview1-final. There's also a 1.0.0-alpha2-final available, but I have no clue if 'alpha' is newer or older than 'preview'.
On the client side I was using version 2.2.2, and there's a whole range of versions to choose from, I tried the oldest and latest, but both versions give me the same "method not allowed" error.
The error is on the client side, on the server side, my breakpoints are not even hit, so it could be an Owin/iis issue as well.
Is there any chart out there that can map SignalR clients and server version compatability? I guess that would be a great step moving forward.
You can't mix the .NET Core 1.x with the older client (1.x or 2.x). You will need to decide which is the best option for you but you need to implement the same compatible version across CLIENT and SERVER.
Check the link for more details but essentially:
What’s Changed?
We added a number of new features to SignalR for ASP.NET Core but we
also decided to remove support for some of the existing features or
change how they work. One of the consequences of this is that SignalR
for ASP.NET Core is not compatible with previous versions of SignalR.
This means that you cannot use the old server with the new clients or the old clients with the new server.
Check the services are injected, possible some is not yet injected in the service container.
When add the signalR service you can enable detailed errors to know what is happening.
builder.Services.AddSignalR(o=>
{
o.EnableDetailedErrors = true;
});
Brock Allen released the new beta version of IdentityManager last week. There are quite some changes in the security model, so the configuration also changed.
He even took some videos (Setting up ASP.NET Identity and Security and IdentityManager) on how to configure the new version properly. These well explain the usage in a classic ASP.NET MVC application, and also ADFS setup, but I couldn't find any help or sample code about how to make it work side by side with Identity Server v3.
Can you please share your experiences configuring IdMgr's remote access with the help of IdSrv3?
After posting that question, I opened an issue on Github and had some chat on IdentityManager Gitter Chatroom, I managed to solve that issue.
There was a sample host configuration in IdentityManager Github Source. Implementing the exact configuration on my project, now I can remotely connect to IdMgr using IdSrv3.
Hope that helpes someone.
I have a Classic ASP / VbScript website that I need to act as an SAML 2.0 Identitiy Provider.
Despite extensive searching I have been unable to find any resource / demo / example to steer me towards a solution.
As I can't find any information I am thinking that it is simply not possible, or is it so obvious nobody needs to ask or that is such an uncommon situation that no resource exists.
Further clarification added
My website.com is coded in Classic ASP / VbScript running in IIS7.5 on Windows 2008 server.
User logs into website.com and can now browse the site.
One section of website.com has links to other-website.com which ordinarily requires login.
To avoid this I can use SAML 2 based SSO to gain direct access to other-website.com by passing over EntityID and unique references from website.com database which correspond to other-website.com database to ensure authentication.
What I really don't understand is from the point that the User clicks hyperlink to other-website.com what I need to do to create and pass over the required information to other-website.com
I think that I have to create some form of encrypted XML document and then POST it via a form to the URL supplied by other-website.com - but I am not sure how to do this and can't find any sample / demo to help.
Hopefully that explains fully what I am trying to achieve!
The normal model is that you have a third-party product (ADFS, OpenAM, PingIdentity, ...) as your IP and your application is the RP (Relying Party).
You don't normally have an application as an IP.
What do you intend to authenticate against?
ADFS / WIF is based around ASP.NET not ASP.
WIF uses WS-Federation not SAML.
To use SAML you need ADFS and that runs on Windows Server.
Check out PingFederate and the Agentless Integration Kit from PingIdentity. Here's an overview of how the integration would work with your application - http://documentation.pingidentity.com/display/AIK12/Implementing+IdP+Functionality. PF would handle all the fancy standards-based requirements and your application would continue to maintain its own session and user authentication functionality. When SSO is needed, you then invoke the PF server. Once you integrate your app, it's very simple to add new service providers via the PF Admin Console.
[Note: I work for Ping]
For anyone reading this question, I would highly recomend taking a look at this article and sample code, I was in the same situation as the OP and found for me it was easier to use this C# ASP.Net code as a starting point (I have little experiance of C# but still got this working quickly and easily). It's clearly comented and works right out of the box and was easy to amend for my needs. In the end it was simpler to implement this in .NET and call it from my ASP application than create from scratch in ASP.
http://www.voiceoftech.com/swhitley/index.php/2008/09/single-signon-with-saml/