I am working on integrating our application with client's Identity management system using SAML 2.0. Below is the requirement
The login screen of our application will have an option for Single Sign On. when clicked user will be directed to the login screen of Identity management system
The Identity provider will validate user's credentials and send us the information back to our application
based on the input from Identity provider the application has to be provide access to the user.
Now, the client has asked us to provide them SAML meta data files. Our application is developed in dot net.
I had a look at component space and ATC Inc components that can be used for SAML generation however I need help to start this.
Can someone help me on this? This is something new which I haven't worked.
Thanks,
Abhilash
If you are looking for a simpler integration than coding support directly into your application, check out the PingOne Application Provider Service (APS) "SAML as a Service" from Ping Identity. A handful of lines of .NET code (or Java or Ruby or Perl, etc) to integrate via a RESTful API and you're done. No need to embed complicated SAML SP code and the security overhead that comes with it [Disclaimer: I do work for Ping].
HTH
Ian
Related
I have built a web-based MVC application in .Net 6.0 that has been in use for years within my company (upgraded recently to 6.0, of course). One of the functions of the app has allowed internal users to send emails and this was working through the Office 365 SMTP until recently. Our parent company introduced MFA and since then, the email function is broken and alternative methods I have implemented are only half working. Based on my research, Microsoft Graph seems to be a good way to replace this email functionality, however I'm lost on how to implement it with my current app.
The application is hosted on our own server with IIS and uses Windows Authentication. What I have not been able to find is a step-by-step guide on how to implement Microsoft Graph API with this setup. I'm completely self-taught and maintain this app on the side, rather than as my main job. All of the examples I've found aren't particularly helpful on the "here's how".
What I do know is that I need to have the app registered in Azure AD. I've spoken with our admin, and that won't be a problem once I know what I need to do. With .NET Core (.NET 6.0), MVC, Windows Authentication, hosted on an internal server with IIS:
Is it possible to implement the Microsoft Graph API? (I believe the answer is yes)
Is there a good step-by-step guide on exactly what I would need to do?
The closest thing I've found is this: https://learn.microsoft.com/en-us/samples/azure-samples/active-directory-dotnet-iwa-v2/active-directory-dotnet-iwa-v2/
Unfortunately, I'm mostly just staring at the code, not able to figure out how I can make use of most of it. I'd appreciate any guidance or recommendations.
Let's tidy up the ideas first.
You have realized windows authentication, that means you can know who is signed in now, or in other words, your sending-email funtion knows who is the sender. Then you also need a page to let users set receive and CC list, subject and email content.
Then you want to use graph api to send email. This required you to have an azure ad application which has Mail.Send permission which permission type is Application(I think using this kind of permission is a good choice in your scenario). By the way, you also need to make sure email senders has their corresponding accounts in azure ad. Because graph api need to know who is the sender, and sender is required to be a member in the tenant which the azure ad application is registered(users outside the tenant can't use the resource in the tenant, right?). For example, users' account information are stored in your local database, and your app linked to your localbase, so your app knows who is the user, but when you try to use graph api/azure ad, you also make sure azure ad know who is the user, so azure ad can authenticate and graph api can know who is the user than allow the user call api.
Normally, in our application, we try to integrate azure ad so that users in azure ad can use their azure ad accounts to sign in, then use the authentication by azure ad, they can call graph api to do some actions. In you scenario, you didn't integrate azure ad authentication, so that using client credential flow to authenticate your app to call graph api is better, so I said give "Application" permission is better. You may refer to this answer and try the sample code in it.
In the code sample, it requires you to set user id as one of the input parameter. If the user passed windows authentication, I trust you can get the user id, but you need to make sure the user id is the same in azure ad. If not, you may also need to set up a matching relationship.
We are using WSO2 IS 5.2.0 for user authentication and SSO across our applications. We have multiple web applications built on java technology.
All the apps are registered in WSO2 service provider and we are able to successfully authenticate user and able to do SSO.
User is prompted for login when he tries to access one of the apps for the first time. Once user logs in, he is able to access any application.
We are using HTTP redirect to achieve this. On the applications side we are using WSO2 java API (org.wso2.carbon.identity.sso.* package) to get the authenticated user details and claims information.
Now we have one more application in .Net (ASP) which we want to integrate into our application suite which should also use the existing SSO infrastructure.
Can someone please let us know how to integrate WSO2 and .Net application for user authentication and SSO. If it is HTTP redirect, then how do we decrypt user information from the SAML Response in .Net application?
Is there any webservice interface available which we can directly call from .Net application which can provide function to get user information by passing samltokenId?
There is a sample written using .NET in here [1] but it seems it is still undergoing development. I have asked the question in WSO2 Architecture mailing list[2] about the state of it (You can follow for more information) but still you can use it to get some understanding (Or as a full working solution maybe).
[1] https://github.com/wso2/samples-is/tree/master/dotnet-agent-saml-sso
[2] [Architecture] [IS] SAML SSO Agent for .NET
I'm very new to the identity management world, so please spare me. :)
What I would like to do, is to have multiple client (MVC) applications that talk to a single Web API application to authenticate their users against. In that Web API application, I would like to use ASP.NET Identity to talk to a database with users.
That way, I could use SSO for the client applications (I guess).
Does that make sense? Could someone help me on my way to implement this (links are also welcome of course)?
I don't know if IdentityServer could help me with what I want?
And as a side question: when I could implement this the way I would like to, how do I deal with the same-origin policy?
Thank you for all the help. :)
I did some research myself during the last few months and I learnt a lot about the identity management stuff. Many of that also thanks to the guys from IdentityServer (and their other projects).
What I finally did was the following (very briefly):
IdentityServer is used as a provider for all client applications. The cookie and OIDC middleware are used.
I used the ASP.NET Identity user service to store the users in an SQL Server database. (The IdentityServer configuration is by the way also stored in a database.)
I set up a Web API service that uses the ASP.NET Identity user manager for user configuration (change password, create new users, ...). It uses bearer authentication with the application with IdentityServer as provider.
As a side note, IdentityManager is used as an internal admin tool to manage all the users.
If anyone is looking for some help setting up his / her identity management system (and thinks I can help): please ask. ;)
Many articles on active profile e.g. Federated Security: How to setup and call a WCF service secured by ADFS 2.0. But that article assumes you want to use AD?
I'm guessing you want to use ASP.NET Identity for the provisioning?
IdentityServer OOTB supports a SQL DB and has basic user provisioning built in. It allows users to authenticate against the DB and supports WIF.
This scenario is also close to what you need, take a look at the answers:
How to implement an OWIN Authentication server with a MVC Web Api content server and an Android end-user apk
I also recommend reading this article:
Decouple OWIN Authorization Server from Resource Server
I've been reading a lot about OpenID and OAuth but having trouble making just a few connections about how they would work in a service-based architecture.
Here's my scenario:
I'm writing new ASP.NET Web API services (RESTful/JSON)
These services will be used by client applications (current desktop website, new mobile website, and possibly a PHP website or JavaScript-only client in the future)
Our desktop website currently uses ASP.NET Membership Provider (webforms)
The new set of API services we are creating should handle everything, including Authentication and Authorization.
My questions are:
Since we have explicit control over the client applications accessing our API (i.e. this isn't a public API but rather one for integrating approved partners) do we necessarily need OAuth?
Would OpenID replace our .NET Membership functionality, or complement it?
Given that we would need to authenticate users with the legacy system using Membership Provider, do we need to use some sort of .NET Membership OpenID Provider, or do we just authenticate as usual and grant the user a Membership Token like we currently do?
I guess, in summary:
I'm writing some new services
They should be usable by ANY approved client application, for users of that client application
We need to continue to support our .NET Membership data
Sorry these are basic questions but I'm sure they're easily answered. Thank you!
Look at ThinkTecture's Identity Server
https://github.com/thinktecture/Thinktecture.IdentityServer.v2
It uses repository patterns for user stores, and uses the default membership provider as the user store - you would be able to easily plug-in your legacy membership provider.
OpenID connect would work on top of your membership provider, and you'd enable the option to only allow registered relying parties - meaning that only your approved clients (applications) would have access.
This seems like a perfect fit - hope this helps.
Matt
We have two old websites in Classic ASP and few websites in ASP.NET 2.0. Our new development is in ASP.NET as well and gradually we might be moving our Classic ASP sites to .NET as well. All these websites use same back-end database.
For now we are planning to move our user authentication to a single server and start using Single-Sign-On(SSO). I am not able to decide what would be the best or right way. Our asp.net websites uses FormsAutentication with CustomMembership and RolesProvider i.e. we use our custom tables instead of default aspnet_membership tables.
Ways I can think:
1: Use Webservice: I can move the authentication code to a webservice and all of our sites can use it. But I am not sure how the Single-Sign-on fits in when we have ClassicASP sites involved.
2: I heard of DotNetOpenAuth: Our external users are created by our internal staff. They can only login using the username/password we provide. So they cannot login using Google,Yahoo or any other username/passwords. So I am not sure if DotNetOpenAuth fits in our case. I saw SSO sample in DotNetOpenAuth download but have no clue how to begin.
If anyone can point me in right direction please. I have gone through various articles and docs but not getting a clue where to begin.
Well, it could be that one of passive single sign-on protocols could be your choice. You can choose between the WS-Federation, SAML protocol or Shibboleth but the first one, WS-Federation is easily supported on .NET with the Windows Indentity Foundation subsystem.
The way WS-Federation works is that it you externalize the authentication/authorization to a separate web application (so called Security Token Service). Each of federated client applications (so called Relying Parties) rely on the information provided by the service.
The basic control flows is like this:
the client points his/her browser to a RP application
the browser redirects (302) to the STS
if STS was visited and the user is already logged into the STS go to 5.
STS shows the login page and validates the user
STS returns to the browser a page containing a signed XML token with all the auth information as well as a tiny javascript to redirect to the RP application
the RP application picks up the token and creates its own authentication based on the provided information
WIF gives you tools to build both STSes and RPs easily and integration of legacy application is also simple - you can either make an effort to handle the protocol at the legacy application level or provide a "brige", a .NET application using WIF which relies on STS and passes the auth information to the legacy application.
What is also great is that with WIF you still stick with old, good notions like Forms Authentication and Membership Providers - it could be a preferred choice of STS implementation.
The WS-Federation protocol itself not only provides the single sign-on but also lets you easily handle single sign off (which is not supported by some other protocols like openid).
Read more on the topic in this book:
http://www.amazon.com/Programming-Windows-Identity-Foundation-Dev/dp/0735627185
Checkout this guide on "Claims-based Identity and Access Control".
The chapter 3 especially: "Claims-based Single Sign-on for the Web and Windows Azure" (Azure is not a requirement).
It well explains the modern Microsoft's way of implementing a single sign-on strategy.
Plus, this TechNet article helped us a lot to get started with WIF and ADFS 2.0.