In a legacy Windows Forms application, users are now identified by an LDAP query. In essence, they scan their badge (barcode) and the application runs an LDAP query to get user attributes.
I know, from a security perspective, this is bad, but usability is more important than security in this case (we're talking about machine operators and they just need to sign-in / sign-off).
Now, we would like to move to a web-based architecture and the simplest thing would be to run the LDAP queries from the back-end to achieve the same.
However, I was wondering if we could switch to a more secure solution using ADFS and RFID/NFC badges, but I can't find any existing implementation. (I'm not looking for 2FA).
So, I'm trying SO, knowing this question can result in opinionated answers: if anyone has experience with a similar use-case, please stand up.
ADFS doesn't do this OOTB.
You could write a custom authentication feature or use the MFA server.
I see you don't want MFA but if you look at the screenshot, it does more than MFA.
Related
I'm in a real build or buy struggle. GCP identity platform would serve almost all our needs.
Basically I want to build usermanagement on my own (including rbac and groups) and ONLY want to solve Login and tokens with the below requirements. I know quite a bit about jwt and authentication in general. The question I'm asking my self is just of its better to build a solution on my own or to use one existing.
Is there any alternative which supports the following:
multi tenancy (at scale >10k tenants)
MFA
social login
SSO with oidc and saml
and of course persistence (using refresh tokens)
Are there any tipps for self building? Are there any alternatives? Any direction is greatly appreciated 🙏
PS:
None of these are what I need: Ory, keycloak, okta, auth0, fusionauth, gluu
USER DATA
When you integrate OAuth there are always 2 sources of user data:
The identity data's view of users
Your own business data's view of users
I think what you are saying is that you want finer control over user data, while also externalising difficult security work.
TOKENS AND CLAIMS
The identity system should be able to include values such as Tenant ID in access tokens, regardless of which data source each value is stored in.
Similarly the User ID in your business data is also likely to be needed in tokens. This value should be provided to your APIs in a consistent way, regardless of how the user signs in, and this is managed via account linking.
DESIGNING END-TO-END FLOWS
The main thing is to think through how these will work, for both new and existing users. This detailed Curity article provides some worked examples.
CHOOSING A SOLUTION
Don't choose a third party identity system until you've designed your end to end flows and clarified your requirements. The key thing about OAuth is that it requires extensible building blocks, rather than being an out of the box solution.
Some companies start with home grown identity microservices, which can become a lot of work, but may be ok in the early days. I always recommend keeping application code portable, so that you can migrate to a better provider in future, if needed.
Are you only considering open source solutions? Azure AD ticks all of your boxes.
You should not implement security logic like authorization or authentication or encryption yourself. IMO its always better to use an existing solution - especially features like MFA are not trivial to implement.
None of these are what I need: Ory, keycloak, okta, auth0, fusionauth, gluu
Why is that? It seems to me most of those are a good option for you - especially the open source ones
The "Two Factor" requirement is configured per user. If we have multiple applications, how do we achieve that
for application A (e.g. a webapp) 2FA is required
but for application B (e.g. a native app), for the same user, 2FA is not required (never, not even for the first time it is used)?
I'm aware of the trustComputer attribute but I don't think it helps for this problem.
Two Factor is at the User level in FusionAuth. This is by design since if the user has selected to protect their account, then they should be forced to provide their additional factor regardless of the Application they are logging into.
There isn't currently a way to change this behavior and we would need to understand the use case in detail as well as any security issues with allowing specific Applications to bypass two-factor authentication.
You can open a feature request on the FusionAuth GitHub issue tracker here: https://github.com/FusionAuth/fusionauth-issues if you want. Please provide as much detail about the use case and why some Applications allow two-factor while others don't. This will help the FusionAuth team assess the implications of adding this feature.
I am studying Authentication and Authorization protocols for my master thesis and I found that probably the best 2 alternatives are OpenID Connect and SAML 2.0 (actually, an European, SAML-based project in which my company was involved 4 years ago called SENSEI).
The purpose of the thesis is the extension of an existing Internet of Things system, which is basically a catalog of streams with information fetched from millions of sensors, and provide AAA (including Accounting), transforming it into an actual Marketplace of streams where people might pay to be subscribed to some streams.
So far, I think OpenID Connect will be a better choice over Sensei and SAML. Reasons are the huge amount of information, documentation, libraries and the companies which support this standard. Also is more developer-friendly and recent. However, I read the following paragraph written by OWASP in this article
While OpenId has taken most of the consumer market, SAML is often the
choice for enterprise applications. The reason for this is often that
there are few OpenId identity providers which are considered of
enterprise class (meaning that the way they validate the user identity
doesn't have high standards required for enterprise identity). It is
more common to see SAML being used inside of intranet websites,
sometimes even using a server from the intranet as the identity
provider.
So I was wondering if you, please, could help me with the following questions:
Do you think also that SAML is maybe more suitable for enterprise projects like mine? Is it true that OpenID is more user-oriented?
I have to think also about the Trust model regarding the sensors in order to be sure that they are reliable sources of information. Therefore, do you think it is a good idea to use the same protocol for: 1) the users who want to be logged in the system and 2) the devices which should prove they are trusted sources with non-faked data?
Related to the previous issue, if I could use OpenID Connect for devices, how could I make them to be authenticated without an email or password? I was thinking in the UUID as identifier but I was told it is not a good idea and also read the same on this StackOverflow thread.
Does anyone know if there exists any well-known protocol to handle or support Accounting in a system? As far as I know OpenID Connect supports Session Management but not Accounting at 100%.
Thanks in advance.
I'm not sure I can answer all your questions here... But I'll give it my best shot, based on my experience and knowledge. And, I'll say that you're being somewhat nebulous with the question (maybe you need to, so as not to expose you billion dollar idea). As such, my answer is really (admittedly) more likely to be considered a discussion point, maybe, than an "answer".
OIDC (OpenID Connect) is new, as is the IoT (Internet of Things). Enterprises are rarely bleeding edge, unless they are dragged into it kicking and screaming by a bigger enterprise partner. That being said, OIDC is built on top of OAuth2.0, so it has understanding out there, and enterprises are really in the take-up phase (IMO), and many of the purchased platforms (like my company's) support it at [current draft-1].
What I think is important to point out is that neither SAML or OIDC is "authentication". It's a standards-based method by which you can carry attributes from an authentication point to an application point that needs to KNOW who or what is connecting to it. Your users could connect one way, your "sensors" another. Or maybe both. Or maybe the opposite. If you're building the next trillion dollar social media site, do you want to limit the ways that your users can join up?
In reference to your question about OIDC and Sensors... I would suggest a certificate-based authentication system, if these things are truly just sitting out there on their own. Again, however, OIDC (and SAML) isn't an authentication system, really. It doesn't do the "front line" of the authentication - it provides a method by which an identity can be carried to the relying party based on a validated claim with a trusted partner. UUID may well be a good choice for the "username" of the device, but it certainly shouldn't be the "password".
Finally, I'm not quite sure what you're asking for with accounting. Are you wanting to charge a user for access to your IoT device streams with, say, microtransactions (interesting concept, if so). Again, neither SAML nor OIDC provide for something like this, at least as far as I am aware of. Accounting (and billing) would have to be built into the application.
HTH -- Andy
I would like to know how does the login procedure work in the Internet sites (e.g. Gmail). I am trying to implement an online application which I want to secure with user authentication.
Could someone give a detailed explanation or point to a relevant site
Many websites use OpenId to allow users to login. OpenId uses OpenId Providers (such as Google) to login. One big advantage is, you do not have a password for the user stored (so if you get hacked, it can't be leaked). Some info: http://de.wikipedia.org/wiki/Openid
ASP.Net has the concept of Membershipproviders, which can in turn use many different ways. See here: http://msdn.microsoft.com/de-de/library/system.web.security.membershipprovider.aspx
There are many ways (another may be OAuth) to create a login, I think you can't talk about one single correct way.
I wrote an application recently, which relies on OpenID for authentication. A lot of web applications these days are moving to OpenID, insofar that they already have userid/password authentication scheme, and OpenID is just an add-on. Since my application is a new one, I decided that it makes no sense to program separate authentication mechanism based on userid/password, when I can rely on OpenID for all the authentication altogether.
But sure as hell, once I presented the application to a customer, she asked "well, how do we create user accounts, and reset their passwords"? Conceptually, she didn't want to make the users create their own OpenID if they don't already have one.
I kind-of had a pre-made response to that, which was: "You can always run your own OpenID server". I guess I didn't put too much thought into this answer though, since many implementations of OpenID server are pretty raw and need a lot of work before they could be run in production.
So, my question is: does anyone here have an experience of running private OpenID server purely for authenticating of her own users. Here are the features I'm looking for it to support out of the box:
Ability to bulk-load user accounts
Self-served password resets through verification email
Administrative features (lock/unlock/disable accounts, troubleshoot, etc)
Presentable look
This doesn't directly answer their question, but how many folks are on the internet and don't have an account with Yahoo, Flickr, AIM, WordPress, Myspace, Google, or MSN? They're all OpenID providers.
I'd argue that for the tiny % of the 'net population who uses none of those services, just point them to Vidoop or MyOpenID and let them get an account with someone who already has a secure infrastructure.
This was my thought initially... But the application is for non-internet-geek type of users, so the expectation is that they may or may not have any of above mentioned accounts.
Another thing is: MyOpenID gives a neat, nice URL for you, when Yahoo (for example) doesn't. Even if you know that a person has a yahoo account, you can't just use username.yahoo.com. Google is same thing - you must first use your google account to activate a blogspot account, and then you have an OpenID, which may or many not correlate to your gogle id. So, if you have a list of users and even if you know they are all on google or yahoo - even then you can't make assumptions about their OpenID url
there are ready to use frameworks.
you only need to put them together. this can be fast done.
you didn't wrote about your platform, but if you like to use php then a look at "zend framework" or "php openid"
I'm using OpenID in my own applications but if I was to go to a customer and they raised the issue about having the passwords and stuff, I'd probably just tell them that the providers would handle that for them. If they didn't like that idea, I'd charge them the extra hours that it would take to setup the membership system. That way you get to charge more and you have a happy customer. I don't think the general public will grok OpenId for some years to come.