[security-dev] PicketLink and Certificate Management API
Pedro Igor Silva
psilva at redhat.com
Sat Jul 5 06:26:01 EDT 2014
We can do something similar as you did in KC, a SPI that you can extend to plug different storage providers.
Bill, would be nice if you could provide some more input about KC cert and key mgmt requirements.
----- Original Message -----
From: "Anil Saldhana" <asaldhan at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: security-dev at lists.jboss.org
Sent: Friday, July 4, 2014 12:58:53 PM
Subject: Re: [security-dev] PicketLink and Certificate Management API
CA is an independent set of libraries. Projects will be able to use them separately.
If the certificates have to be stored in a data store such as db,ldap then it is better to use the PL IDM as an implementation detail.
> On Jul 4, 2014, at 9:46 AM, Bill Burke <bburke at redhat.com> wrote:
>
> Would be nice if CA could be as separate as possible from PL IDM API.
> Then we could use it in Keycloak.
>
>> On 7/3/2014 8:43 PM, Pedro Igor Silva wrote:
>> The motivation behind partition performing CA tasks is that partitions are in essence security domains or realms.
>>
>> We are already working in an independent code base for cert and key mgmt.
>>
>> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: security-dev at lists.jboss.org
>> Sent: Thursday, July 3, 2014 1:41:26 PM
>> Subject: Re: [security-dev] PicketLink and Certificate Management API
>>
>> Pedro,
>> if the partition can perform the tasks of a CA, that is fine.
>>
>> But we need a separate independent code base to do the Certificate
>> Management.
>>
>> We may have a circular dependency here because the Cert Mgmt stuff may
>> want to use PL IDM to interact with the data stores - file, ldap,DB. :)
>>
>> Regards,
>> Anil
>>
>>> On 06/18/2014 01:35 PM, Pedro Igor Silva wrote:
>>> Yeah, that is the idea too. Giriraj Sharma wants to help us in the future to provide an UI based on that.
>>>
>>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "security-dev >> \"security-dev" <security-dev at lists.jboss.org>
>>> Sent: Wednesday, June 18, 2014 3:32:30 PM
>>> Subject: Re: [security-dev] PicketLink and Certificate Management API
>>>
>>> Sorry, the there was a error on the example. This is the correct code:
>>>
>>> X509Certificate userCert = authority.issue(certRequest); // issue a cert for user and sign it with the CA key
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>> To: "security-dev >> \"security-dev" <security-dev at lists.jboss.org>
>>> Sent: Wednesday, June 18, 2014 3:28:40 PM
>>> Subject: [security-dev] PicketLink and Certificate Management API
>>>
>>> Hi,
>>>
>>> We're looking to provide a API to easily enable Key and Certificate Management to PicketLink-based applications.
>>>
>>> The idea is turn a partition into a Certification Authority, responsible for issue, validate, revoke and renew certificates for the identity types (eg.: users, devices, etc) associated with it.
>>>
>>> In the future, we also want to provide:
>>>
>>> - RESTful Endpoints to perform not only certificate operations, but also manage keys. Specially public keys. Probably using JSON Web Keys (JWK).
>>> - Better support for html5 and mobile applications that require some kind of support for certificates, assymetric keys, signature and encryption. Specially when using JWT and JOSE.
>>> - Support Java KeyStores to load and store keys.
>>>
>>> So far we did something like:
>>>
>>> CertificateConfig config = new DefaultCertificateConfig();
>>>
>>> // set config with signature algo, cert sign algo, default validity, bit length, etc
>>>
>>> // create a CA based on a existing partition
>>> CertificateAuthority authority = new DefaultCertificateAuthority(partition, config);
>>>
>>> User user = // get user
>>>
>>> CertificateRequest certRequest = new DefaultCertificateRequest(user, config)
>>>
>>> X509Certificate userCert = ca.issue(certRequest); // issue a cert for user and sign it with the CA key
>>>
>>> We're still working on it. But would like to check your feedback or opinions about requirements and use cases.
>>>
>>> Regards.
>>> Pedro Igor
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
More information about the security-dev
mailing list