Expose SecurityLevel on server-side

[ejona86]

This is an out-shoot of #7711. Basically, there is not a generic way of determining the level of security offered by the transport for RPCs on server-side. This can be approximated by looking for the SSLSession, but that doesn't work for ALTS and maybe some future TLS approaches.

CC @pavolloffay

[ejona86]

API review meeting:

• Want to add support for SecurityLevel to server-side
• While attributes is available, we prefer a first-class method: ServerCall.getSecurityLevel(). This mirrors the first-class method on CallCredentials.RequestInfo
• We don't see much reason to add such a method to client-side currently, as it is a rare use-case to look at the security after the request has already been sent; CallCredentials can be used for the while

[ejona86]

General implementation approach:

• Add the new method to ServerCall. Have it return SecurityLevel.NONE or throw UnsupportedOperationException; unclear which is more appropriate at the immediate moment
• Add an implementation to ServerCallImpl, and just have it return getAttributes().get(ATTR_SECURITY_LEVEL)

Over time we'll probably try to make the security level more first-class in our lower-level APIs and delete the ATTR_SECURITY_LEVEL key, but that is completely separate.

[sanjaypujare]

• Add the new method to ServerCall. Have it return SecurityLevel.NONE or throw UnsupportedOperationException; unclear which is more appropriate at the immediate moment

Throwing UnsupportedOperationException is more correct whereas returning SecurityLevel.NONE could be potentially incorrect.

[ejona86]

@sanjaypujare, I don't quite agree with "more correct". For security APIs it is normal to lower the perceived level of security in the face of uncertainty. As far as I'm concerned, we can always return a lower security level than actually used, with the understanding that code requiring higher levels may stop functioning. Downgrading can be much more predictable than random exceptions being thrown at times.

I think the question is "who benefits?" Debugging the exception is definitely easier and more clear. If the method is not implemented, what will callers generally do? If they will error, then the exception could be convenient and not harmful. But if they will try to continue, then using NONE can be more appropriate.

[sanjaypujare]

Yes, I understand that returning SecurityLevel.NONE is safer even when the actual security level is higher and that's a justification for returning SecurityLevel.NONE in the base class if you ignore the correctness angle. Also:

• this is a new API so any users of it need to know the behavior and cannot be surprised by the exception
• if a caller requiring higher security fails then it matters less whether it fails because the returned value is SecurityLevel.NONE or there was an exception.

But I am not opposed to returning SecurityLevel.NONE in ServerCall.

[sanjaypujare]

fixed by #8943