I am going to preface this by saying I am a novice in this field. Our system has a large number of users, some of whom, log in using SAML authentication, others use the forms authentication on the home page, and some use a custom built Single Sign On solution. This happens because different clients prefer different modes of authentication.
We are looking to streamline authentication so that it is not a function of the web application, and we are therefore going by the claims model. One of the infrastructure options to build the STS is the Thinktecture Identity server.
My question is this:
- Is is possible to have multiple STS for the same web app, and if so, where does the switching happen? I.e if user1 uses SAML, how is this user's credentials sent to that specific STS?
Also, is Thinktecture the right infrastructure to be building something like this, or should I look at something else?
Related
I got absolutely confused when trying to understand the differences between MicrosoftAccount, AzureAD and OpenIDConnect authentications.
I am trying to build a .Net Core MVC app that allows some users to authenticate with local accounts, but some with Microsoft accounts. I do need to have a local user in DB for both types of authentications as I have some custom authorization mechanisms built on that.
I started with creating the app from template and selected "local accounts" authentication. Then I added the MicrosoftAccount authentication according to this tutorial (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins?view=aspnetcore-3.1). This is using Microsoft.AspNetCore.Authentication.MicrosoftAccount and seems to be working fine.
However, when I create a new app from template and select "work or school account" authentication I can see it uses a different library - Microsoft.AspNetCore.Authentication.AzureAD.UI. It seems to do the same thing. I can see there are events I could hook into to connect the AAD user with my local DB.
Looking through the web I found some other tutorials that were using OpenIDConnect for the same purpose.
How are those methods different? Which one should I use and why?
In future I would like to be able to query the user's directory for a list of other users. Would that requirement be easier met with either of those three methods?
MicrosoftAccount: This is the login with a general Microsoft account, using OAuth2. This is also what Microsoft will refer to as “private account” and useful when you want to authenticate someone just using their Microsoft login as an external authentication provider. This is similar to how you would sign in to sites with your Google account.
AzureAD: This is the sign in to a specific Azure tenant. This is often understood as a “work or school account” because it doesn’t sign people in using a public account but rather some account bound to some organization. Usually, you would have an Azure tenant where you have direct users (or configure it to allow external users) but you want to control access through that Azure AD.
OpenIdConnect: This is the general OpenID Connect protocol which you can use to sign in with many different authentication providers because it is a protocol that many of them will support. You can use OIDC to sign in to either of the above (and many other services) but that will require you to do some more configuration as you will need to figure out specific addresses for example.
You can always use the OpenIdConnect or the OAuth authentication scheme to authenticate with most authentication providers but those are the “manual” schemes which will require you to configure additional things. All the other authentication schemes, including MicrosoftAccount and AzureAD but also the other ones like Google or Twitter build on top of those protocols and come preconfigured so that you do not need to set up much else. So those are mostly for convenience and for more specialized support.
So when you want to authentication through Microsoft or Azure, then you should choose MicrosoftAccount or AzureAD. Which of those depends on where you want to authenticate with. If you have an Azure AD, then you should use that.
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'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
I'm working on a WCF project that will be our new service layer.
These services will be called by 2 separate clients, the first of which is a WPF application and the other is an ASP.Net web application. The WPF client will be run by internal users and will authenticate with the service via domain authentication and run under the context of that user. The other will be used by external users and needs to authenticate using some separate mechanism then impersonate a "WebUser" account on our domain.
I'm reading a bit about Windows Identity Foundation and it sounds like this might be a good fit. Am I right in thinking I could have 2 token services, one for domain authentication and one for something like ASP.Net membership authentication (Or some similar equivalent) and have each client get it's token from the relevant STS and pass that along to the WCF service?
I'm assuming there is an STS I can use out of the box for domain authentication, but will I have to implement the second one myself to authenticate web users? I can't find a lot of information on this.
Am I thinking along the right lines or should I just be creating duel endpoints for each service each with a different authentication mechanism? Or should I be doing something completely different?
Thanks
The big advantage of using Claims-Based authentication / WIF is that both the task of authenticating the user AND the administration of the user's properties are moved way from the applications to the STS/Identity provider.
You are developing a service layer but the true benefits of using WIF will be for the applications written on top of your layer. The WPF application will no longer need to connect to the AD and fetch the user's groups to figure out what they are allowed to do. The groups will already be visible as claims in the token the user/WIF provides.
The web application (is it just one web application or more?) will no longer need the ASP.Net Membership database with accompanying user administration. This functionality gets moved to the STS.
There is a cost. (There always is, somehow...) Claims-Based authentication has a rather steep learning curve. It takes a while for the quarter to drop for all people involved.
So the answer to your question depends on what kind of users the web application(s?) built upon your service layer have and how many. And how much they wish to know about them. Can you perhaps trust Google / Facebook / Windows Live for authentication? Are the users already in an existing database within your domain? How much work will it take to maintain the user directories? Do your marketing people wish to send them emails regularly? Et cetera.
This is probably not just for the service layer's developers to decide, but something to discuss with people in the rest of your organisation.
If the benefits are not particularly big, the alternative is to simply keep these responsibilities at the web application's server. Each web application will have a good old ASP.Net membership database, it'll authenticate the user all by itself. When asking queries from the service layer, it'll present its web server certificate plus specify the user's name and type.
If the benefits are big enough, you can in principle use ADFS 2.0 for everything. It can also store external users nowadays and it's free if you already have Active Directory. Or the ThinkTecture 2.0 server that Ross recommends. It's easier to customize and perhaps your systems administrators and security folks will not be too enthusiastic about opening the firewall to the ADFS server.
Microsoft has some good reads on WIF, in particular an Overview of Claims-Based Architecture.
You should take a look at identity server as it can indeed handle this scenario.
The person who leads the project above has a great pluralsight video on this exact scenario! You need to sign up to watch it, but they offer a free trial.
Basically you get a token from the identity provider (windows ADFS for the internal client, and what ever you decide for the external users). You will give this token to the federated gateway (identity server probably, but it could be Azure ACS). This will return an authentication token that you can then use with your service.
I have a need to implement a STS-IP server for our web applications and services. The server will need to issue SAML tokens for the following scenarios:
Business partner submits their SAML token which is converted to a SAML token with the claims required for our applications. This token is used to access our Web Applications and Services.
Our public facing applications need to have a user sign in (via forms authentication) and then access our web applications and services with a SAML token.
Our clients (without a STS trust) needs to authenticate with our STS-IP server, get a SAML token, and use that token to access our WCF services.
In all 3 scenarios, we need to have custom claims on the SAML token that our applications and services use. The thought is once we identify the user, we would look up their authorization in our back-end systems and attach claims.
In these scenarios, you can assume the back-end authentication store is a custom implementation with authentication stored in Active Directory and authorization stored in a database.
So my thought has been, we need to create a custom STS-IP server using something like Windows Identity Framework. But I have also been reading that you should not do this because it can take some time.
Can I use an off-the-shelf STS-IP server? Everything I've seen is a mapping between one system to another (SAML to SAML or AD to SAML).
Why will it "take a long time" to build a production ready STS-IP ? I built one using WIF very easily, but I guess I don't understand the risks in doing this.
In terms of "It will take a long time", the documentation showing how to do this is very poor. See here: http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/257d93be-165e-45a6-a277-fc7ed2286e7d/
Anyhow, you'll simply need to look over the code samples that Microsoft provides: Google for Identity Developer Training Kit. That should help you get started.
Why are you not considering using ADFS? If the backing store for authentication is AD, then ADFS is probably a good candidate to evaluate.
Before writing you own STS, you may want to check out this blog and closely review the features that you may need in the STS. Just because you can build one yourself, doesn't always mean you should.
extending adfs to multiple identity and attribute stores
They "why not" is relatively simple: Why take weeks to build something that will probably only handle a single use-case when you can put in off-the-shelf STS in a day that will cover all sorts of things your company may come up with? Building it yourself will also require you to become an expert in SAML (which is probably not the best us of your company's time).
Check out --
http://www.pingidentity.com/our-solutions/pingfederate.cfm
Good luck -- Ian
Agree with #eugenio - why not use ADFS?
ADFS can only authenticate against AD as discussed but it can derive authorisation attributes from AD / LDAP / SQL server
The nuts and bolts for an STS are available in VS 2010 plus the identity tool kits. A simple STS can be quickly prototyped.
There are some examples available. StarterSTS is already mentioned plus SelfSTS.
The hard part is getting the security right especially if this will be part of a production system. As per "Steve on Security" Build your own Directory Federation Service:
It may sound like I think it’ll be a
synch to develop this system and have
it work securely, but in reality there
is a lot that will need to go into it
to protect the network, the employees,
and the data this could possibly
interact with. It is tough to develop
applications securely. It is far
harder to develop secure applications
whose sole responsibility is security
related.
That's the reason that all the samples on the Internet have disclaimers in bold:
Do not use in a Production environment