Can I use Attribute Based Encryption (like CP-ABE scheme) and Oauth 2.0 to implement the Authorization, Confidentiality and Authentication (i.e. with FB, Google, Twitter etc.) in a web-application ?
Is there any example or framework ?
Is there any suggestion to use ABE with Oauth ?
Thanks
It doesn't make much sense to use OAUTH with CP-ABE. Those materials are on different levels. In fact, the OAUTH standard doesn't mention encryption at all, it just requires HTTPS without specifying a SSL/TLS version or cipher suite. Also OAUTH is concerned with resource access, thus authorization (but often misused to authenticate objects).
From the CP-ABE perspective there is no logic either. The idea of PKI is to establish a secure and trusted channel, not to do authentication or authorization.
If I have misunderstood the question, please clarity.
Update
Yes it is possible, but still subject to research, and therefore I wouldn't put too much trust in the method yet. What the paper describes it possible, but I doubt it will be used on large scale.
I am not an expert but want to comment here.
The key feature of OAuth2 is to facilitate authorization
The key feature of ABE is to facilitate encryption using attributes that helps in achieving privacy.
[for confidentiality and authentication, explore something else].
Since authorization and encryption/privacy are different aspects of security, they can be combined in innovative ways [such as this].
Related
I have two questions, really. I'm learning authorization in ASP.NET Core using the OAuth scheme for my company's authority. The thing is, on the final (3rd) leg, requesting a token, I need to authenticate the client (client id/client secret) using basic authentication (as per RFC 6749/2.3.1) but from what I have seen from the traffic client credentials are sent in the body instead.
I have a very hard time finding good documentation on the AuthenticstionBuilder.AddOAuth extension method so my first question is for tips where I might find a proper walkthrough that explains how to use the options and the four events supported? What I have found is people explaining how to set it up for this or that authority (such as GitHub, Facebook etc.) but none explains how the scheme implementation is designed. As a last resort I will have to check out the source code but if anyone can provide some links to a good explanatory walkthrough I would really appreciate it.
My second question is if there is a way to use Basic Auth for obtaining the token, as I describe above? I assumed there would have been an event where I could do that but my experiments indicates the three available events aren't suited for this.
If you use PyPI for uploading files, you can authenticate using a username and password, or you can authenticate using just a token, and sending the string __token__, and then the token with a prefix:
To use an API token:
Set your username to __token__
Set your password to the token value, including the pypi- prefix
You can see more details on their page here:
https://pypi.org/help/#apitoken
This seems quite clever - it doesn't break the experience for people using old style credentials, but allows you to tie a reduced set of privileges to a given token, which seems safer.
What is the name of this pattern, where both ways of authing are supported like this? I mean beyond the name 'token based authentication', as that doesn't account for the fallback offered here.
And beyond the obvious downside that only needs to get their hands on the token to send possibly malicious requests, what are the other downsides to this approach?
I'm working with RSS in a project, and it seems a nice way to provide access to legacy RSS readers, while still supporting more use cases of an API.
PyPI admin here: we call that a "compromise" 😉. PyPI needs to be entirely backwards-compatible with existing clients that only support basic HTTP auth, so this was really the only option available to us with that constraint.
I'm not sure there's a better name for it. There are some other examples of this in use in varying ways:
https://api.data.gov/docs/api-key/ (API key as username, empty password)
https://stripe.com/docs/api/authentication (API key as username, empty password)
https://docs.github.com/en/rest/overview/other-authentication-methods#via-oauth-and-personal-access-tokens (Regular username, API key as password)
After tad more digging through the issues on the warehouse project on github it turns out that the passwords/password approach with the pypy- prefix are actually much more powerful than I first thought.
Based on a kind of auth credential called a Maracoon, as described in this paper from google
This paper introduces macaroons: flexible authorization credentials for Cloud services that support decentralized delegation between principals. Macaroons are based on a construction that uses nested, chained MACs (e.g., HMACs) in a manner that is highly efficient, easy to deploy, and widely applicable.
Although macaroons are bearer credentials, like Web cookies, macaroons embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests. This paper describes macaroons and motivates their design, compares them to other credential systems, such as cookies and SPKI/SDSI, evaluates and measures a prototype implementation, and discusses practical security and application considerations. In particular, it is considered how macaroons can enable more fine-grained authorization in the Cloud, e.g., by strengthening mechanisms like OAuth2, and a formalization of macaroons is given in authorization logic.
There's a video introducing the idea - Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud,
After a quick look around I've found libraries written in python and go, and c.
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 have made a simple WCF-REST-service, published it to Azure and activated SSL with a X.509-certificate.
I'd like to setup some authentication for this service as well. I could solve this very easily by sending a credentials-header in clear text since all traffic is now encrypted, but I am planning to use some kind of federated authentication instead so that users can take advantage of Single Sign-On.
This field is relatively new and yet seems to already be littered with obsolete technology, making it difficult for someone with little experience to find current best practices and solid toolsets. I'm hoping somebody with significant experience can provide some insight and give us all an up-to-date jumpstart.
What are the modern, state-of-the-art options for federated authentication?
Is OpenId the only technology for this?
Is it difficult to implement SSO?
Can a relatively inexperienced yet reasonably intelligent developer implement this based off a few tutorials? Or are the underlying technologies too complex, making a third-party API/framework more desirable? (like DotNetOpenAuth)
For Azure and WCF specifically, is "Windows Azure Active Directory Access Control" really necessary, or would that be like swatting a fly with a sledgehammer?
Authentication, Authorization and identity federation are HUGELY complex subjects and should not be taken lightly. The reason security is a big, complex problem is that its extraordinarily hard to get right!
If you don't already have a great deal of experience in internet identity & security, don't try and roll your own auth mechanism: Correctly and securely implementing an authentication mechanism is very, VERY hard.
For example, in your scenario above, you've not accounted for ensuring that the creds you pass in the HTTP header are anonymized for each site you want to present them to and that they expire after a period of time, that they cannot be replayed, that they cannot be synthesized by a malicious 3rd party, etc.
I strongly encourage you to use a pre-existing authn mechanism and supporting framework. In fact, since you're an Azure user, the easiest way to add end-user identity federation to your site is to use the new authn features of Windows Azure Mobile Services
If you still want to learn more about identity and identity federation, I encourage you to research this subject before choosing the right type of authentication to use:
Start with A Guide to Claims-Based Identity and Access Control (2nd Edition). This will give you most of the background and knowledge necessary to understand this subject sufficiently to make sound decisions.
Once you've got a good grip on this subject, I recommend reading everything that Vittorio Bertocci has written over at http://cloudidentity.com.
HTH.
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.