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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: security-dev(a)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(a)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(a)redhat.com>
> To: security-dev(a)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(a)redhat.com>
>> To: "security-dev >> \"security-dev"
<security-dev(a)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(a)redhat.com>
>> To: "security-dev >> \"security-dev"
<security-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/security-dev
> _______________________________________________
> security-dev mailing list
> security-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org