All,
OpenStack API issues token after successful authentication. However, it is only valid for 1 hour.
Is there any workaround or possibility to extend token's lifespan?
Thanks & Regards,
Ganesh.
You may want to take a look at the solutions used by Heat, the OpenStack orchestration engine.
Heat needs to be able to execute actions on behalf of a user at some point in the future. Heat cannot simply store a token because, as you have stated, tokens expire.
Heat offers two solutions to "deferred authentication".
Keystone Trusts
Stored passwords
There are lots of details about how Heat handles this here and here.
There are some API examples of keystone trusts on the eNovance blog, and some more over here.
Related
Could someone please explain to me why a bad actor could not create the following disruption for potential new users to my app?
The bad actor:
Obtains a list of emails from the dark web or some other nefarious source.
Acquires my Firebase keys by inspecting my app javascript -- yes my app is minified, but it would still be possible.
inserts malicious javascript code into my app sources on their local browser. The malicious code uses the Firebase sdk and my app keys to create accounts for each email address.
While there is no possibility that the bad actor could gain access to validated accounts;
nevertheless, creating these accounts would generate unsolicited email verification requests to the owners of the emails and it would also interfere with a smooth account-creation experience for those users when they actually do want to signup.
Am I missing something here?
firebaser here
As Dharmaraj also commented: the Firebase configuration that you include in your app is used to identity the project that the code should connect to, and is not any kind of security mechanism on its own. Read more on this in Is it safe to expose Firebase apiKey to the public?
You already in your question noted that creating a flurry of accounts doesn't put user data at risk, which is indeed also correct. Creating an account in your project does not grant the user any access to other user accounts or data in your project yet. If you use one of Firebase's backend services, you should make sure that your security rules for that service don't do this either.
The final piece of the puzzle is that Firebase has many (intentionally undocumented or under-documented) safe guards in place against abuse, such as various types of rate limits and quotas.
Oh, and I'd recommend using the local emulators for most of your testing, as that'll be faster, doesn't risk accidentally racking up charges due to a quick coding mistake, and (most relevant here) doesn't have the rate limits in place that are affecting your e2e test.
I'm writing a web app that is very tied to a different app (Twitch), so my plan is to only offer logging in through them. I'm trying to come up with an auth scheme for my app, and am thinking about implementing it by just packaging up the OAuth2 creds I get from Twitch, and setting that as a JWT cookie. See diagram of auth design
I'm having a hard time finding another example of someone doing or suggesting this, so I get the feeling I'm missing some reason why this is a bad idea, but I can't figure out why. The cookie is a JWT so it's signed, and since the tokens are all from Twitch they can be revoked on their end if necessary. And since all the Twitch creds I need are in a cookie, I don't need to store any access tokens in my DB.
So am I missing something that makes this a bad idea, or is this a secure enough solution to use?
This is a really interesting question. Sadly the answer to this is "it depends", based on the risk / reward to your app and business. Let me try to clarify that to help.
Let's assume that in your system authentication is core to the service. So essentially if your users cannot authenticate then they are not able to access the system.
Using a third party to provide authentication has many pro's and con's. Obviously the pro's are around not having to manage credentials, password resets, attempted attacks on the credentials etc. Also, there are advantages to the customer of not having another set of credentials to manage.
The con's largely are around the dependancy on the third party, if Twitch goes down then no-one can use your system. (This might be true anyway, based on your description).
Essentially, what I recommend is that you weigh up the pro's and con's in your environment. Assuming that the pro's outweigh the con's then using OAuth2 is a great way of authenticating.
While I don't have an example to hand of a website using only 3rd party auth I do believe the industry is getting there. Many sites have 3rd party auth at the top of their sign in options showing a preference over creating a new set of credentials. You don't have to look much further than StackOverflow that has the following order:
Google
GitHub
Facebook
StackOverflow account
In short: In GCP credentials can be restricted with application restriction and with API restriction, but Identity Toolkit API cannot be restricted on Expo mobile application.
-In web both restrictions work
-On android/iOS API restriction works but (as I have tested, correct me if I'm wrong) application restrictions does not
Now if using email/password authentication there is an issue.
There is a huge insecurity here as if anyone gets to know your API key (you define in initializeApp and so you connect to Firebase with and so use with Identity Toolkit API).
They can only by knowing that key call Firebase Auth REST API "Sign up with email / password" from anywhere and create users for your project!!
Am I wrong, missing something or can this be prevented somehow?
Things you can do to prevent this:
In "GCP>credentials>Identity Toolkit API" you can lower "Queries per minute" and "Queries per minute per user"
You can in "Firebase>Authentiction>Sign-in method>Manage sign-up quota" lower the quota from same IP address to minium (but does this help in case of android/iOS application?)
But there is no completely secure solution unless you can application restrict your API key as far as I know.
I got the following answer from Firebase support and since there has not been answers I will add this as correct answer for anyone looking solution for same thing or seeing this question.
First of all, I would like to thank you for choosing Firebase to
implement your application. I know that these kinds of situations
could be frustrating, let's work together to provide the best solution
for you.
I have checked your case and I would recommend that you reinforce your
Security Rules, because this is not a security risk, as long as you
secure access to the data within your project correctly for your
requirements, as it is mentioned in this external entry.
We don’t have a way to know the origin of those emails, even if they
were created by real users through your app, but if you identify fake
accounts you can use Cloud Functions to delete all emails registered
with that pattern using Auth triggers. Alternatively, you can delete
the accounts after an established time without activity using Schedule
Functions.
Additionally, if you don’t want to have users on your application, you
would probably need to use the Admin SDK and authenticate the
application by service account instead.
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).