We have an Internet facing Web Application running, and recently our company made some agreements with a 3rd-party company which owns another web site. The idea is to provide access to this external web site to our current customers. Our users will click on an internal link in our solution which will open a new browser window with the third party site. User will not need to authenticate again in the 3rd party company site.
We have agreed to issue SAML2 tokens for our users, with a set of claims used by the 3rd-party site to query an present a personalized view to our users
Something important in our scenario is that users are already authenticated in our web site when they decide to access the 3rd-part web site.
What is the best way to implement all this?
I am thinking on implementing a custom-STS using the WIF SDK to generated those SAML2 tokens and pass then using HTTP POST (cookie) to the 3rd party site. If this is the right approach, then any pointers, tips?
Will ADFS make any difference?
Thanks for any help
Sounds like you'll be playing the role of Identity Provider - responsible for handling the "manual" authentication of the user and generating SAML responses to give the user SSO to the 3rd party website.
Implementing your own IdP is not trivial (there are a handful of specifications to understand), so unless you have your heart set on this as a development project, you may want to consider a COTS like Microsoft ADFS, PortalGuard (for whom I work) or Ping Identity.
Since you asked about ADFS specifically, it has native support for Active Directory as the user repository and has some interesting features with its claims transformation engine (if you get into a complex SP-IdP chaining scenario). Besides SAML it also supports WS-Federation which is important for integration with the other offerings in the Microsoft stack.
If your application is ASP.NET, then connect your application to ADFS.
So to get to your application, the user has to log in.
Then for the link to the 3rd party application use the IDP Initiated scenario (IdpInitiatedSignOnPage Class Overview). This sends a SAML2 token to the 3rd party application. ADFS will handle SSO for you.
To do this, you will have to configure the 3rd party application as a SAML one rather than a WS-Fed one.
Related
So we are using IdentityServer4 for our web applications, all is good.
We have a new requirement from a client to allow them to perform SSO via their ADFS system using WsFederations, we already provide this for another one of our older web applications that is not tied into IdentityServer4 yet.
Ideally we would like to tie WsFedereration into IdentityServer4 so it is in one place.
Does anyone know if it possible to use IdentityServer4, so we redirect to IdentityServer4, identity that this particular client (possibly via an alternative URL), then IdentityServer4 authenticates against ADFS, collects the claims (probably basic, e.g. email/username/etc) , and we then supplement them with additional claims for access, and pass back to the web application.
What I'm trying to achieve ideally is to not change the existing Web Application, and to sort the plumbing at IdentityServer4, and the Web Application wouldn't know or care if this user was IdentityServer4 only or
IdentityServer4 + WsFederation. This would be useful for other clients across our applications to easily integrate in the future.
Alternatively I could deploy another version of the Web Application that authenticates directly with my clients ADFS system. However this seems a waste of server resources/maintenance for just one small client.
I had a look at the external options (where you click google on or near the IdentityServer4 Login Screen), is there a way to automatically redirect to the ADFS without event seeing the IdentityServer4 implemented Login screen.
Is this possible?
Thanks,
Jon
This was released 2017, see the example at
https://github.com/IdentityServer/IdentityServer4.WsFederation
I've been reading a lot lately about WEB API authentication mechanisms and I'm a little bit confused regarding how to implement my Web API authentication mechanism, I'm thinking on using Token based authentication but I'm not sure if it is the right choice.
Basically my Web API will manage all the operations needed and it will store the users of my website as well the API users(in case they have to be separated).
I want to support the following
User can register on my website and apps using their G+ or Facebook account or an already created username from my service, as well they will be to login using their social account.
If the user is not logged in they won't be able to post Items but they will be able to see the Items, think something like Craiglist.
Let's say the user is a developer and they want to post the items through some software they created instead of going through the website and posting one item at a time, how do I allow this?
Now, my questions are: 1) When a user registers on my website, do I have to create a (public key/ secret key) for it subsequent access token , so I can use my API from the website as the user checking if they have access to certain endpoints?
2) Do I have to assign a (public key / secret key) for my website so I can consume the API when the user is not logged in?
3) The same as above for mobile apps
4) How do I allow users to (sign up / sign in) using G+ or Facebook?, if they log in using any social network how am I going to secure my api?
Please, any answer will be really appreciated.
Thanks
For ASP.NET Web API 2, I would recommend you to use the default Owin OAuth2 authentication. It's a standard form of authentication well documented enough. If you do not have enough knowledge about OAuth2, read the RFC.
With Web API 2, ASP.NET moved to a new security model, called ASP.NET Identity. There is this really good video that explains the basics. The point is that starts from scratch, ignoring traditional basic, forms, or windows authentication.
A lot of learning material is on the ASP.NET website.
For local, individual accounts (questions #1, #2, and #3), look through this tutorial - here basically your own server will act as an OAuth authorization server, and the Owin OAuth2 implementation will take care of generating access token and authenticating them. Since you'll be using the OAuth 2 standard, it will be basically the same for mobile as well.
For external accounts (question #4), read through this tutorial. There are official libraries for third-party authentication for the major providers:
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.Twitter
Microsoft.Owin.Security.MicrosoftAccount
It would helpful to also learn more and understand the new OWIN specification, that describes how web apps need to created for the .NET framework, and the Katana project (Microsoft's OWIN implementation).
Follow this tutorial for most of your requirements http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/ Logging in via facebook/G+ MVC already has the helpers commented out. You would get the credentials by setting up key's via the third party apps and then store the identity.
I'm struggling with these concepts and having trouble finding good resources on the web.
We are looking for ways to switch out custom implementations tightly integrated into our application for standards based authentication and authorization.
Our scenario is as follows:
A simple web site (may be an app in the nearby future)
A user must log in or otherwise gain access (i.e. there's no "guest" content or other things you can do as a guest)
The site uses its own web services (REST and/or SOAP) on the backend, but it might use 3rd party web services or exposes its own services as 3rd party services for other applications
Authentication may very well be done by an external provider: Users carry a smartcard and we'd like to have one simple identity provider which reads the smartcard information and sends it back to my simple web site (so I know who the user is and what his role is for instance)
Other sites might use other methods of authentication (simple username/password for instance), so we might need a configurable Service Provider??
I'm currently looking at OAuth (2) to implement for authorizing use of our REST Services (is it also useful for SOAP?) to our web site, perhaps with a simple "Client Credentials Grant" type.
But for authentication, I'm still none the wiser. There is OpenID, but is it easy enough to build your own OpenID Identity Provider? There is Shibboleth, but it seems to have a steep learning curve for doing custom stuff. And I've looked at just building something from scratch based on the SAML Authentication Request Protocol with an HTTP Post binding. Are there any other options?
Please keep in mind that we want to be flexible with our authentication. For a certain site, we might want to do the smartcard thing, but for another maybe simple username/password login with LDAP.
If it's helpful still, I personally thought about doing it myself, then discovered a bunch of third parties. I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
Could you help me determine which authentication protocol I should use for the following use case? I am new to this area of development and am a little bamboozled with all the technical information out there - so a 'for dummies' answer would be greatly appreciated.
I have an online learning website that hosts courses in English Language. A requirement has arisen that we should integrate with 3rd party Enterprise Systems (because we sell the courses to Enterprises).
The primary requirement is to allow 3rd party systems to redirect their users to my site and have them access it with there 3rd party system credentials (I believe this is called Single Sign-on?). The 3rd Party systems are obviously remote systems and I am focusing more on capability than 1 specific customer / integration.
So, what I am trying to understand, is what capability should I offer to allow this to happen? I am trying to develop a generic 'developer toolkit' so that I don't have to be bogged down in lots of individual integrations as and when they arise.
I have read that there are lots of protocols / things in this space (SAML, OAuth, OAuth2, OpenID, Shibboleth, etc) - so I wondered where I should focus my attention and research? Which is the most common among Enterprise systems (CRMs, etc)?
Also, as a sub-question. Is OAuth deprecated or sneered upon now that OAuth 2.0 is released?
Any help is truly appreciated!
Thanks all.
SAML 2.0 is the most popular protocol for Single Sign On when it comes to Enterprise systems. Most if not all enterprises are able to provide SAML based SSO for third party websites.
Ideally, if correctly implemented the enterprise would need to configure their system to send your website SAML assertions (Identity information in the form of XML) and you would the information in the assertion to log the user in.
The Enterprise would be called the Identity Provider (IDP) in this case and your website would be called the Service Provider (SP)
There are a number of open source libraries available that allow implementing SAML (Spring etc.), alternatively your existing servers may have the capability as well.
Once you have the base implementation done, you can then choose to do two things:
If the user does not exist in your DB, create a new record and allow the user access.
The enterprise that you are integrating with must supply a list of users before hand and then you can allow only the users that are present in the DB.
Although the second option has a lot of overhead and not used very often.
---------------------------- Answer to Comments-------------------------
It depends on the way you would setup the interaction.. There are two ways to setup SAML SSO:
SP initiated SSO: This means that the users always access your site and then is redirected to the IDP for authentication. The SAML token is sent back to your site post authentication.
IDP initiated SSO: This works in a way that the IDP generates a SAML token and directly posts it to the SAML endpoint of your website.
If you are using option#1 and users are already logged in step C would not be needed since the user is already logged in and the token can be directly generated.
For option#2 only the steps D and E would be needed. I would however urge you to strongly to not omit the SP Initiated SSO implementation since some IDPs do not support IDP initiated SSO.
Hope this helps
Avi
I've been scratching my head over this issue for over a week. We have a web app that we would like to implement SSO for. SSO with windows active directories of our clients (i.e. we essentially need to authenticate against our clients' active directories without much trouble)
The only thing I am 100% sure about is that I will needed a security token service that will have to communicate with an Identity Provider. My question:
Which service is most suitable for the above scenario (AD FS? OpenID & OAuth 2.0? SAML 2.0 and shibboleth?)
How will I connect to the active directories of the clients? Maybe I'm not understanding how the STS is to be used, could anyone clarify? I'm working with an Azure Web App
Will there have to be a different IdP for each client? Will the client have to do more than just give us standard information? What would this info be?
...should I be using Windows Identity Foundation?
HELP :( ... this is an SOS
If anyone could clarify at all, I will forever be grateful. I normally upvote anything I find helpful and accept whichever answer is the best so feel free to answer with what you think might be useful in helping me understand how I can achieve what I am after.
These are the three options I know:
As you mention one option is ADFS this solution means that your customers should install and expose Adfs. ADFS means Active directory-Federation Services, so in this case your application needs to speak WS-Fed (not oauth). Typically if the user is inside the LAN adfs uses integrated auth, if not it will prompt credentials.
WAAD is a new service from Azure, it allows companies to expose their directories to use in cloud applications. With this approach your customers need an account in Azure, create a directory and use the dir sync agent. Your application will talk SAMLP with WAAD.
Auth0 is an authentication broker that allows developers to use social but also enterprise identity providers like AD but also google apps, waad, adfs, salesforce, etc. if your customer only has AD you will provide him an msi for a windows service, that will bridge the company AD with your auth0 account, you can have as many AD as you want. Your application speak oauth with Auth0. This agent supports kerberos authentication as well. The following graph explains this solution:
Disclaimer: I work for Auth0.
WIF doesn't support SAML or OAuth.
Your application is in Azure.
Suggest add WIF to the application and then "bind" to Azure Active Directory. In VS 2013, use the "Change Authentication" feature for this.
Make the application multi-tenanted.
Each customer has their own tenant. User DirSync to sync. each customer AD with their AAD tenant. (That gives same sign-on). Adding ADFS to each customer gives single sign-on.
However, the customers will probably push back on this because of perceptions around security.