1

I have been playing around with authentication-flows and noticed that when I restart the web server the URL's no longer work, they are all invalid. I walked through debugging but I am still a bit lost as to exactly why, though I have a lot of good reasons why it should happen (and I am sure you do also).

I want to make a service which will be distributed to multiple containers and when a request comes in any of them could serve it. As the solution stands right now, it looks like I will have to make modifications to make possible.

What exactly is making the URL invalid? and what changes could I make to make my proposed solution possible?

Thank you in advance.

In response to Ohard's comment:

1. Why the URL is invalid

Let me tell you how I get the error. I deploy the war, submit forgot password. Receive the email to reset my password then stop the war. When that happens my reset password page extracts the enc. I then stop and redeploy the war. After isend a rest request with the enc and a new password to the /rest/setNewPassword mapping, then receive:

09 Jan 2016 03:50:48,799 [http-nio-8082-exec-1] ERROR web.rest.UserActionRestController - Failed to decrypt URL content aX8uaOWkqAUQN2xOzlPAOHJjPZaxBwho7.yoMeUtMnJA

in ohadr\crypto\service\CryptoService.java there is an exception on line 261:

throw new CryptoException("Failed to decrypt URL content " + based64EncryptedContent, e);

which I then use a break point to find:

java aes javax.crypto.BadPaddingException: Given final block not properly padded

I am sure if you try to reproduce this issue, you will find the same results...

Note: when I do this without the re-deploy everything works great!

2. How to make auth-flows work as SaaS

There are three use cases I want this service to fulfil:

  1. Currently, If I host a service and it goes down without a fail-over, people who have URL's will be unable to use their links when it comes back up. I want them to be able to use the links regardless.

  2. (untested -- but will be soon) Similar to the second, If I host this service on multiple docker containers I believe that it will not be able to receive link that did not orginially come from its container, therefore containers could not share unsorted loads. It should be able to read any of the enc's and process it.

EDIT:

1. Why the URL is invalid

An even easier way to test this is just to submit a forgotten password, get the email and then stop the war. Redeploy it, then click the link. I got this stack trace:

https://drive.google.com/file/d/0Bwa-JXbjFUDueXVMWWJibjY2Zm8/view?usp=sharing

Don't worry about csrf it is not enabled.

tmpg
  • 83
  • 6
  • actually you post here 2 questions - why the URL is invalid, and how to make auth-flows work as SaaS (if I understand the requirements...). can you post more data about the exception you get , with stack trace, and explain a bit more what is your flow? – OhadR Jan 09 '16 at 08:01
  • @OhadR see edit for an answer to your question – tmpg Jan 09 '16 at 09:12
  • I've added an answer to your 2nd question here. See below. – OhadR Jan 11 '16 at 19:11

2 Answers2

1

1. Why the URL is invalid

As it looks like, the ICryptoUtil instance is re-created after you redoply the war.

CryptoService.java line 38:

return  ContextLoader.getCurrentWebApplicationContext().getBean(ICryptoUtil.class);

I suggest for you to do a small test. Encrypt a string twice, now and after the redeploy and compare the results. If you got 2 different results then your crypto is not capable to decrypt an encrypted string of another crypto instance.

EdiZ
  • 441
  • 4
  • 13
0

@EdiZ is right.

To be more accurate, every time your web-app loads, Spring loads all the beans. Among them are Crypto's library beans, such as CryptoUtil and CryptoProvider, and if you look carefully you will notice on DefaultCryptoProvider.loadMasterKeys() that a new key is generated.

I believe that explains the behavior you see.

Currently, If I host a service and it goes down without a fail-over, people who have URL's will be unable to use their links when it comes back up. I want them to be able to use the links regardless

It seems to be a duplication of your first question; I think that the first issue will have to be resolved in order to make it work as you wish. If the server reboots, all the links become invalid - the users will have to click again on "forget password" (for example) and get a new link - it is for you to decide how big this deal is.

If I host this service and I do have a failover I assume the failover will not be able to read URL that is not from it originally. It should be able to read any of the enc's and process it.

I assume that you have to develop some more persistence, so the server can decrypt URLs that were not generated by it...

Hope that helps.

OhadR
  • 8,276
  • 3
  • 47
  • 53
  • 1
    @Ediz and OhadR, I am testing this out now. I will let you guys know when I am finished. Thanks for the advice! – tmpg Jan 10 '16 at 04:54
  • @tmpg cool. if one of the answers solves/explains your issue, do not forget to mark it as "accepted" :) – OhadR Jan 10 '16 at 07:17
  • I finished building it. I missed the DefaultCryptoProvider.loadMasterKeys() somehow when I was looking through it. I knew why it was probability happening but not exactly why(which is the most important part imo). Thank you both for the help. I just spun off the crypto class into its own container and wrapped rest api around it. Therefore the authentication server can spin up and down. I also added in fail-safe when it stores the key temporarily in a shared db in case the crypto service went down – tmpg Jan 11 '16 at 23:23
  • feel free to drop a link (here and in my GitHub proj) to your project, where you have the crypto as a stand-alone WAR. i might add it to auth-flows :) – OhadR Jan 15 '16 at 20:38