[keycloak-dev] Certificate Management, Directory Services and Device Registration

[Anil Saldhana]

On 01/02/2014 12:15 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 23 December, 2013 4:11:25 PM
>> Subject: Re: [keycloak-dev] Certificate Management, Directory Services and Device Registration
>>
>> On 12/23/2013 03:21 AM, Stian Thorgersen wrote:
>>
>>
>>
>> ----- Original Message -----
>>
>>
>>
>>> From: "Bill Burke" <bburke at redhat.com> > To: keycloak-dev at lists.jboss.org >
>>> Sent: Friday, 20 December, 2013 8:42:06 PM > Subject: Re: [keycloak-dev]
>>> Certificate Management, Directory Services and Device Registration > > > >
>>> On 12/20/2013 3:27 PM, Anil Saldhana wrote:
>>
>>
>>>> Some of this is what I hear from users, customers and the industry. Also
>>>>>> see below: > > > > On 12/20/2013 02:23 PM, Anil Saldhana wrote:
>>
>>
>>>>> Bill brought out some thoughts in my mind which I want to capture here >
>>>>>>> to see what your thoughts are: > >> > >> * Certificate Management >
>>>>>>> - We need a good system to CRUD certificates.  The only good Java
>>>>> based > >> oss I have seen is EJBCA.
>> EJBCA is a no-go as it's looks like it's heavily dependent on JavaEE. For
>> LiveOak we need whatever libraries we use to be non-JavaEE.
>> Stian - let me take a guess here. You think maybe writing a thin REST based
>> system for certificate management is better?
> I haven't thought much about it, but yes I think everything should be exposed through REST. Re-utilizing existing stuff is great though, but as long as we want to embed Keycloak into the LiveOak container it can't require a JavaEE runtime.
Creating certificates is possible with Bouncycastle + JDK. I guess what 
is left are UI and storage mechanisms.

>
>> EJBCA is an old project. I guess they started out as EJB based services.
> Had a quick look at docs and looks like it is built as a set of EJBs and deployable to JBoss AS
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>>>>>> * Directory Server/Services > >> - We have ApacheDS and OpenDS (or
>>>>>>>> the ForgeRock version) as two > >> possibilities in Java based
>>>>>>>> directory servers. I am unsure if we have > >> really explored
>>>>>>>> building a solution for directory services.
>>>> * Another important consideration is Active Directory. It is an > >
>>>> ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we > >
>>>> really need some type of Open Source solution to this ecosystem. The > >
>>>> core starts with directory services or a facade. > >
>>>> A huge part of Keycloak's value-add is it provides the UI for login, >
>>>> registration, acct/credential/device/realm management.  If these AD/LDAP
>>>>> services are read-only, then there's not a lot Keycloak can offer you.
>>>>>> Also, for Keycloak 1.0.Final, we're focusing solely on securing Web
>>>> Apps > and RESTful services.  We can't have too many tangents or feature
>>>> creep.
>> We can't wait to long to support mobile devices (at least Android and iOS).
>> These would be required by both LiveOak and AeroGear. Not sure if that's
>> before or after a 1.0.Final though. AeroGear guys can probably help us out
>> here though, as they're working on OAuth2 libraries.
>> Agree. Having REST based MBaaS dealing with mobile devices may be critical.
>> Apache UserGrid is the new entrant in the oss space.
>>