On 01/02/2014 12:15 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Monday, 23 December, 2013 4:11:25 PM
> Subject: Re: [keycloak-dev] Certificate Management, Directory Services and Device
> On 12/23/2013 03:21 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com> > To:
>> 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
>>>> 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
>>>> 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.
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
>>>>>>> * Directory Server/Services > >> - We have ApacheDS
and OpenDS (or
>>>>>>> the ForgeRock version) as two > >> possibilities in
>>>>>>> directory servers. I am unsure if we have > >>
>>>>>>> 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
>>>>> Also, for Keycloak 1.0.Final, we're focusing solely on securing
>>> Apps > and RESTful services. We can't have too many tangents or
> 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.