Windows CCAPI design sketch

[Jeffrey Altman]

Alexandra Ellwood wrote:
>
> On Jan 30, 2008, at 12:53 PM, Jeffrey Altman wrote:
>
>>>
>>> CCAPI v2 is deprecated.  All CCAPI v2 functions return errors when 
>>> called.
>> This decision is going to cause problems for all currently deployed 
>> applications which support the use of multiple credential caches.  
>> These applications use the CCAPIv2 to enumerate the available 
>> credential caches in order to determine which caches are available.   
>> There has been no other interface for them to use.  By failing to 
>> implement CCAPIv2 on top of the new implementation there will be no 
>> transition mechanism for organizations to use when upgrading to KFW 
>> 4.0 and CCAPIv7.
>>
>>>
>
>
> I'm aware that the CCAPI v3 was never shipped on Windows.  I made this 
> decision based on several factors:
>
> 1) Statements made in meetings last fall that Secure Endpoints did not 
> believe any third party Windows applications were using the CCAPI and 
> that it should become an internal API on all platforms (with callers 
> using the krb5_ccol_* and krb5_cc_* APIs instead).  As a result I 
> operated under the assumption that all existing callers were part the 
> KfW product and could be modified to use the CCAPI v3 in the next 
> release containing the new CCAPI implementation.
I never said that there were no third parties do not use CCAPI.  CCAPI 
has been used directly by applications going as far back as I have been 
working with KFW.  I used CCAPI in Kermit 95 back in 1998.

I do believe that application developers should be provided krb5_ccol_* 
so that they do not have to use CCAPI directly in order to enumerate the 
credential caches.   The dependency on CCAPI for this functionality is 
just wrong.  Unfortunately there have been no other options for 
developers on the Windows platform.
>
> 2) The original draft of the cross-platform CCAPI implementation 
> submitted by Secure Endpoints had all CCAPI v2 functions deprecated.  
> In fact the error "CC_NOT_SUPP" those functions return in the new API 
> was chosen by looking at the code submitted by Secure Endpoints.  For 
> reference, this code was checked in at 
> "src/lib/ccapi/client/ccapiv2.c" in revision 18200 of the krb5 trunk.
>
Deprecated does not mean "not implemented".  Deprecated means "to 
express disapproval of".  A deprecated API is one that marked as "should 
not be used". 

CC_NO_SUPP was the error code returned in code that had not yet been 
implemented.  
>
> However it is still possible to implement a shim layer between the 
> CCAPI v2 and CCAPI v3+.  I believe 1-2 new IPC calls are needed for 
> the iterators but that shouldn't be too hard.  If someone is 
> interested in submitting patches which implement these changes we 
> would be happy to review and integrate them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20080130/334abb76/attachment.bin