Expand AuthenticationUtils::isSchemePermitted

[quidryan]

The current isSchemePermitted methods give us the identity and entity auth, and identity and keyx scheme, but not at the same time. To properly enforce a mix of Entity Auth schemes and KeyX schemes, we would need to know about both of them at the same time. E.g. only allow Unauthenticated entity auth for an identity, IIF they're doing SymmetricWrappedExchange key exchange.

The simple change would be create a new method AuthenticationUtils::isSchemePermitted that takes both entity auth scheme and key exchange scheme. The bigger problem is where that would be called from. MSL currently assumes that each Entity Auth and KeyX Auth will call the appropriate methods on AuthenticationUtils. Neither have both of those schemes handy. Can a form of isSchemePermitted be called from msl-core itself instead of relying on the individual schemes?

[quidryan]

Another angle on this is that we might want more than just the scheme for enforcement. We might need something in Entity auth or Keyx might be relevant to the enforcement, e.g. a system id during KeyX or a CDM Id in Entity Auth. In the KeyX case, we could squirrel anything that we need in the KeyResponseData, and just not serialize it out in the getKeydata method. I don't know how we'd share something learned at Entity Auth with a AuthenticationUtils::isSchemePermitted.

[wmiaw]

The only way I can think of to address more complex and domain-specific permissions checks is to use a more complex and domain-specific custom approach, instead of the AuthenticationUtils example interface. That would let you do some of the specialized things you're describing. Any relevant data would be available in the EntityAuthenticationData or MasterToken provided to KeyExchangeFactory.generateResponse().

Currently, MSL core has no knowledge of the original entity authentication scheme that was used when renewing a master token. If any combination of permitted entity and keyx schemes are permitted for that identity, that isn't an issue.

However the iff scenario you describe is not supported. It would require either changing the contents of a master token to include the entity authentication scheme originally used, or always including the scheme in the issuer data. I would worry about either of these approaches being very specific and eventually leaning towards bloat of the master token definition as more data needs to be carried forward from the entity authentication step to the key exchange operation, or error-prone use of the issuer data (MSL core trying to manipulate what is otherwise opaque data: the issuer data).

In the short term, may I suggest using a different more specific and custom permissions interface instead of the example AuthenticationUtils interface? Longer term we can figure out what changes make the most sense for the example AuthenticationUtils interface based on the actual use cases that need to be supported.

[quidryan]

I'm not concerned about when renewing a master token. By that point, we've already trusted the identity. I'm looking for solutions when first doing entity auth, where keyx used is an important signal. I agree that it shouldn't be in the Master Token.

I'm fine using another interface than AuthenticationUtils, if there was a place where I had a handle on Entity Auth and KeyX at the same time.

[wmiaw]

One version of the KeyExchangeFactory.generateResponse() function has EntityAuthenticationData and KeyRequestData as parameters.

[quidryan]

+1 Thanks for the pointer.

…

On Jun 2, 2017 6:33 PM, "Wesley Miaw" ***@***.***> wrote: One version of the KeyExchangeFactory.generateResponse() <https://github.com/Netflix/msl/blob/master/core/src/main/java/com/netflix/msl/keyx/KeyExchangeFactory.java#L151> function has EntityAuthenticationData and KeyRequestData as parameters. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAV_P_G2wuEUoYFgmpaTw1Hnj-8L_sq2ks5sALf5gaJpZM4Ntn2t> .