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.
Related
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.
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
Background: I am trying to create an SMS API service. The developers have a Dev ID, and an API secret key assigned to their developer account. The developers will be creating apps which will issue calls to my API. But the application issuing the call must be verified first.
Issue: The main issue i have is with authentication. I read up on OAuth and pretty much uderstood it. I read through this presentation (Slide 71-82). All OAuth articles talk about the OAuth 'dance' or the 'love triangle'. My problem seems to be, that i dont see a proper triangle in my case. Or, a better way to put it would be, the triangle doesn't seem to be complete.
What i mean by that is, in the case of lets say, LinkedIn, trying to make some app which helps users associate their LinkedIn acc with twitter, OAuth makes complete sense. Because LinkedIn needs to get resources from twitter ON THE USERS BEHALF (Cuz the user HAS A TWITTER ACCOUNT). In my case, only the consumer has a developer account registered with my service. The end-user doesn't have any credentials for the consumer to ask on behalf of. So how can i implement Oauth? So what will the consumer ask the provider? Will it only state that "watch out, here i come?". Cuz that seems pretty pointless unless its asking for a request token in exchange for an access token. But in this case since the end user doesnt even have an account, the steps seem useless.
So, i cant figure out how to go about this authentication issue. Ive tried thinking about using php sessions so it can help me associate a token with the particular client who is using the API. But the REST/OAUTH purists seem to disagree on the usage of sessions in authentication. They claim that OAuth is a standard which has proven itself and that is what I should use instead of coming up with my own obscure schemes.
From your description it seem that you're in a two party scenario only (developers write code which accesses your API on their own behalf, not on behalf of an end-user), so that means indeed that doing the full 3-legged oAuth scenario isn't needed.
You could use pretty much any authentication scheme and that would work (API Keys, other oAuth grant types [see below] or even ID/Secret combinations. In the oAuth world:
Look at the other oAuth 2.0 Grant types: especially resource owner PW grants - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.3. It's slightly better than username-password because the PW isn't passed across the channel all the time (it passes once though) and it assumes the developer writing the code is the owner of the credentials.
Look at oAuth v1.0: this different in various ways to v2.0 but one feature it does have which some people like is the way tokens are used - which is rather than being passed across the wire they are used to generate a hash in the client and then the hash is verified on the server side. It's more expensive and complex than checking a key but it's less prone to attack.
In the non-oAuth world, if it's primarily a server resource used by developers directly, an ID/Secret or API-Key pattern is probably more than sufficient and it's much easier to implement for your developers.
Re: oAuth - if you're doing any type of user auth then definitely stick with the standard - the stuff is complex and having libraries out there really helps. If it's developer-api you likely don't need to go that far.
If you want the API to be secure in an ideal world anything which requires the security token to pass across the gaps should be secured using SSL, especially if that client code could be running on a mobile device or laptop which might communicate over wireless. If this isn't the case, someone could jump in an copy a token from one of the devs.
The only one of the protocols above that avoids this is the oAuth 1.0 variation since the secret never leaves the client but is used to hash instead. But it's complex. Last one to look at is the Amazon AWS pattern which does hashing similar to oAuth 1.0 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html and people emulate quite a bit.
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 am currently building a custom forum type site for video games. Therefore, my audience would be anyone who likes video games (ie somewhat tech savvy).
The only sensitive information will be their login/email/password - no payments of any kind. AND The user will be required to have a unique username.
My Questions Are:
1) If I build a user login with their email/username & password, do I need to implement SSL?
2) Would OpenID be a better alternative to writing a custom login?
I know the whole custom login vs OpenID is a current ongoing debate, I was just looking for advice on my particular situation...
Well , I like video games but I don't like Open ID and have avoided using sites simply because they use Open ID. Seeing a login page without the usual username and password security on SO I just thought "WTF?" and don't, even now, like the idea of an 'Open' ID. An 'ID' is something that can be 'stolen', we're told many times - so having your ID made 'open' just sounds the same as making your ID 'really easily stealable'. Like having an open bank account. Now the tech behind it may be very safe, but you're asking me to take it on trust that the people who didn't think through the actual name of their product very smartly have been really, really smart and found a way to let my ID fly around multiple big social sites in perfect safety? Hmm...
The short: Use a traditional login.
The long:
People understand traditional logins - people do NOT understand openid. Facebook connect cheapens your site and for the most part, so does twitter. So, use a traditional login. It's only the computer savvy that understand the notion of "saving you from yet another login".
Some people even think you (if incorporating OpenId) are gaining access to their presonal top secret gmail (openid account) information. They don't like that.
Incorporating openid seems simple at first, but beware - it is a nightmare. It is a monster that will only grow and grow.
So... don't use it, use a traditional login.