You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Jiajia Li (JIRA)" <ji...@apache.org> on 2017/05/03 14:15:04 UTC

[jira] [Resolved] (DIRKRB-478) Refine and enhance the client side library

     [ https://issues.apache.org/jira/browse/DIRKRB-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiajia Li resolved DIRKRB-478.
------------------------------
    Resolution: Fixed

> Refine and enhance the client side library
> ------------------------------------------
>
>                 Key: DIRKRB-478
>                 URL: https://issues.apache.org/jira/browse/DIRKRB-478
>             Project: Directory Kerberos
>          Issue Type: Sub-task
>            Reporter: Kai Zheng
>             Fix For: 1.0.0-GA
>
>
> From discussion in mailing list:
> {quote}
> There are good feedbacks from Steve recently. Based on discussions with him and Emmanuel, I assembled below thoughts.
> KrbClient and its relatives like KrbOption would be broken down according to supported mechanisms and functionalities.
> Eventually we would have these client side APIs for applications to use.
> == KrbClient ==
> Focus on classical Kerberos protocol, allowing to request/update tickets to KDC using password, keytab, credential cache and etc.
> == KrbPkinitClient ==
> Support PKINIT mechanism, allowing to request tickets to KDC using anonymous and x509 certficate.
> == KrbTokenClient ==
> Support standard JWT token, allowing to request tickets to KDC using JWT token.
> == KrbPwChange ==
> Change passwd client, interacting with KDC using the change password protocol.
> == KrbAdmin ==
> KDC admin utilities compatible with MIT kadmin tool in either local or remote mode. In remote mode interacting  with KDC, though no spec standardizing that.
> Note there're already keytab and credential cache utilities.
> All these components will define their own options with good specific descriptions; For the components that use configurations, krb5.conf is default format; For the components that interacts with KDC side servers, common network and message support will be used; All will provide both intuitive functions and advanced function that supports directly calling into the underlying layer.
> These library APIs can be used to write tools like kinit, or embedded in applications.
> It would be good to provide corresponding server side components or supports, but not mandatory. Better to have at least for easier tests.
> {quote}
> This issue will track the related tasks.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)