[
https://issues.apache.org/jira/browse/MESOS-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yan Xu updated MESOS-1383:
--------------------------
Description:
Currently Authenticator doesn't tell Master about the principal of the
Authenticatee it just successfully authenticated.
To reliably capture the user name, we should save the username from a
*successful* [CRAM-MD5
response|http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10#section-2].
The proposed API change:
{{process::Future<bool> Authenticator::authenticate()}} ->
{{process::Future<Option<string>> Authenticator::authenticate()}}
Return value:
- Upon successful authentication, the principal of the Authenticatee is
returned (previously 'true').
- None is returned if the authentication is unsuccessful due to incorrect
credential (previous 'false')
- A Failed future is returned for other failure cases same as before.
During interaction with SASL the best way I've found to to expose the username
is through the {{SASL_CB_CANON_USER}} callback.
{noformat:title=SASL_CB_CANON_USER definition}
/* callback for a server-supplied user canonicalization function.
*
* This function is called directly after the mechanism has the
* authentication and authorization IDs. It is called before any
* User Canonicalization plugin is called. It has the responsibility
* of copying its output into the provided output buffers.
*
* in, inlen -- user name to canonicalize, may not be NUL terminated
* may be same buffer as out
* flags -- not currently used, supplied by auth mechanism
* user_realm -- the user realm (may be NULL in case of client)
* out -- buffer to copy user name
* out_max -- max length of user name
* out_len -- set to length of user name
*
* returns
* SASL_OK on success
* SASL_BADPROT username contains invalid character
*/
{noformat}
Inside this callback I can save the username the Authenticatee provides and
then return the exact username as the canonicalized username. This is
admittedly not the intended use of the callback but I can't find anything
better and this doesn't seem to have any issue: if the authentication fails,
this username is not returned to the caller of
{{Authenticator::authenticate()}} (i.e. Master).
was:
Currently Authenticator doesn't tell Master about the principal of the
Authenticatee it just successfully authenticated.
To reliably capture the user name, we should save the username from a
*successful* [CRAM-MD5
response|http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10#section-2].
The proposed API change:
{{process::Future<bool> Authenticator::authenticate()}} ->
{{process::Future<Option<string>> Authenticator::authenticate()}}
Return value:
- Upon successful authentication, the principal of the Authenticatee is
returned (previously 'true').
- None is returned if the authentication is unsuccessful due to incorrect
credential (previous 'false')
- A Failed future is returned for other failure cases same as before.
During interaction with SASL the best way I've found to to expose the username
is through the {{SASL_CB_CANON_USER}} callback.
{noformat:title=SASL_CB_CANON_USER definition}
SASL_CB_CANON_USER
Calls an application-supplied user canonicalization function.
SASL calls this function before doing anything with a username.
{noformat}
Inside this callback I can save the username the Authenticatee provides and
then return the exact username as the canonicalized username. This is
admittedly not the intended use of the callback but I can't find anything
better and this doesn't seem to have any issue: if the authentication fails,
this username is not returned to the caller of
{{Authenticator::authenticate()}} (i.e. Master).
> Expose the authenticated principal through Authenticator::authenticate()
> result
> -------------------------------------------------------------------------------
>
> Key: MESOS-1383
> URL: https://issues.apache.org/jira/browse/MESOS-1383
> Project: Mesos
> Issue Type: Task
> Reporter: Yan Xu
> Assignee: Yan Xu
>
> Currently Authenticator doesn't tell Master about the principal of the
> Authenticatee it just successfully authenticated.
> To reliably capture the user name, we should save the username from a
> *successful* [CRAM-MD5
> response|http://tools.ietf.org/html/draft-ietf-sasl-crammd5-10#section-2].
> The proposed API change:
> {{process::Future<bool> Authenticator::authenticate()}} ->
> {{process::Future<Option<string>> Authenticator::authenticate()}}
> Return value:
> - Upon successful authentication, the principal of the Authenticatee is
> returned (previously 'true').
> - None is returned if the authentication is unsuccessful due to incorrect
> credential (previous 'false')
> - A Failed future is returned for other failure cases same as before.
> During interaction with SASL the best way I've found to to expose the
> username is through the {{SASL_CB_CANON_USER}} callback.
> {noformat:title=SASL_CB_CANON_USER definition}
> /* callback for a server-supplied user canonicalization function.
> *
> * This function is called directly after the mechanism has the
> * authentication and authorization IDs. It is called before any
> * User Canonicalization plugin is called. It has the responsibility
> * of copying its output into the provided output buffers.
> *
> * in, inlen -- user name to canonicalize, may not be NUL terminated
> * may be same buffer as out
> * flags -- not currently used, supplied by auth mechanism
> * user_realm -- the user realm (may be NULL in case of client)
> * out -- buffer to copy user name
> * out_max -- max length of user name
> * out_len -- set to length of user name
> *
> * returns
> * SASL_OK on success
> * SASL_BADPROT username contains invalid character
> */
> {noformat}
> Inside this callback I can save the username the Authenticatee provides and
> then return the exact username as the canonicalized username. This is
> admittedly not the intended use of the callback but I can't find anything
> better and this doesn't seem to have any issue: if the authentication fails,
> this username is not returned to the caller of
> {{Authenticator::authenticate()}} (i.e. Master).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
