Talk:Requests for comment/Service-oriented architecture authentication

Similarity to AuthStack
How different is this from AuthStack? This RfC seems like just a generalized version of the latter. Can they just be merged? Parent5446 (talk) 18:14, 9 June 2014 (UTC)


 * This RFC focuses on authentication in a SOA world, and formulates some architectural goals. One of those goals is a separation of concerns and isolation. Most code should not have access to sensitive user information, so that security issues in random features don't lead to an exposure of sensitive information. Another goal is to push authentication to the lowest layers (storage service) wherever possible to avoid the risk of a confused deputy & address the issues of different services collaborating to provide specific functionality.


 * The solution presented in the AuthStack RFC does not seem to address several of these goals. This leads me to believe that the goals of the two RFCs are actually different. -- Gabriel Wicke (GWicke) (talk) 18:32, 9 June 2014 (UTC)


 * I think "Authentication" is a bad name for this RFC, but can't think of a better one. Maybe "Inter-service user identification, authorization, and session management"?
 * While AuthStack deals (primarily) with Authentication in MediaWiki, this RFC is about MediaWiki acting as an Identity Provider for other services, and how to efficiently make those assertions. If we make a MediaWiki Authentication Service, then it would need to account for all of the stuff discussed in AuthStack, as well as how MediaWiki core would consume those. I don't think that discussion should happen until we have the inter-service session management pieces working in production. CSteipp (talk) 22:39, 12 June 2014 (UTC)

Tokens
gwicke and I had talked about using JWT's for identification. I did a quick test to see the size, and encoding basic information about the user, issuer, validity timestamps, and the list of user rights that user has generates a JWT that's about 4k. The RS256 signature was about 600 bytes larger than HS256, using a 4096 bit rsa key. CSteipp (talk) 22:40, 12 June 2014 (UTC)


 * I'd expect the size to be mostly determined by the key size. Do we need 4096 bits, especially with key rotation? We might also be able to gzip + base64 encode the value for the benefit of plain HTTP users, although this should not do much for the signature. -- Gabriel Wicke (GWicke) (talk) 22:41, 12 June 2014 (UTC)


 * 2048 would probably be ok if we actually do key rotation. Key management is hard, but if someone is willing to stay on top of it, we can assume that. So that takes the signature down to about 300 bytes. Also, we would want to use RS512 to get equivalent security to HS256, so using my test user gives:
 * Uncompressed: RS512 JWT = 4054 B, HS256 JWT = 3755 B
 * Compressed: RS512 JWT = 2482 B, HS256 JWT = 2183 B
 * So ~2.5k overhead on every request. CSteipp (talk) 23:35, 12 June 2014 (UTC)