Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Authorizing only some users #4
With apache mod-auth-openid, you can filter users:
If I am not mistaken, there is no way to do that with mod-auth-ticket. Is there a plan to implement that?
It would be useful in situations where you are hosting static content that you want to limit to a specific set of authenticated users.
It is possible, or at least, it should (= if not, that is a bug) be possible.
I think I tested this long long time ago, but I'll check again.
Internally, MAT converts incoming "signed cookie" into HTTP "Authorization:" header.
Note there is no way for you or MAT to know user's real password - because that part is offloaded to external authentication service (IdP, in OpenID/etc speak). You can just come up with any random text for password field and emded that when generating a cookie - just make sure both MAT and mod_auth use same "randomly-generated" password. I think HASH(username + mod_auth_ticket_secret) would do.
Just FYI, my plan is to make MAT embed other information embedded in "signed cookie" into HTTP header (or environment var), so it'll be extremely flexible when used in conjunction with mod_magnet (lua script).
I was recently hit by mod_auth limitation that it still does not handle group authentication, so I decided to embed group information into "signed cookie", let MAT convert it to HTTP header, and use mod_magnet to check (and filter) that incoming request.
On Fri, Jul 12, 2013 at 1:33 AM, Taisuke Yamada email@example.com:
Note there is no way for you or MAT to know user's real password - because
Another question: from what I understand, in the php form, the (username +
This cookie is stored into the user's computer for a few seconds (and then
If I still get this right, with this key, one could forge identities, using
What do you think? Am I not getting something right?
Yes, you're correct. And that is why MAT uses time-salted, hashed temporary key for actual encryption. Even if attack-able, that window of opportunity will be limited to 5-10 seconds. My assumption was that it should do to protect from replay attack based on leaked cookie.
However, as you pointed out, current encryption method is not strong enough if a user who wants to attack another user can control one's username length. Stronger scheme was planned with "srp:" scheme, but that is still not implemented.
I think I can come up with "crypt2:" scheme, which adds username as a salt for temporal key generation. That way, each temporary key is now "per-user", so there's no way one user can attack another user. I'll try that this weekend.
Just as a record, primary reason why MAT uses simple XOR-based scheme is that I wasn't able to find "common encryption" that works across various programming languages. Obviously there's AES/etc in OpenSSL, but each openssl wrapper (in each programming language) seems not to agree on actual encryption parameter, and was not interoperable. So when I made MAT to work with PHP+openssl generated cookie, that implementation had a issue with another. Thus I ended up with current scheme.
Why do you even want to encrypt username:password?
From what I understand, it does not really matter if this information goes
I have the impression that you could put this username:password combination
Again, I just have superficial understanding of your code, that I read