[keycloak-dev] Abstract SMS support

Stian Thorgersen stian at redhat.com
Mon Aug 17 05:35:38 EDT 2015


I'm not convinced about this approach, I think it would end up being complex and we'd continuously get request on tweaking it to support other providers.

Having a simple Java interface with something like (just a quick mock, not the suggested interface):

SMSProvider:

* Status sendMessage(String message, String phoneNumber)

Would be fairly easy for users to implement and would work for all services.

----- Original Message -----
> From: "Thomas Raehalme" <thomas.raehalme at aitiofinland.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 17 August, 2015 11:29:34 AM
> Subject: Re: [keycloak-dev] Abstract SMS support
> 
> On Mon, Aug 17, 2015 at 12:18 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > > However it might be a good idea to include a generic HTTP/REST
> > implementation
> > > which you could configure through the admin interface to deliver SMS
> > > messages to any service supporting HTTP? I'm pretty sure this would
> > satisfy
> > > most users.
> >
> > Not sure how that would work. AFAIK SMS providers have their own
> > proprietary rest endpoints as well as authentication mechanisms so I don't
> > see how we could create a generic implementation.
> >
> >
> 
> You would need to implement a template mechanism where the Keycloak data
> (for example the recipient number and message text) is provided as
> keywords, and the admin defines the template utilizing those keywords. It
> would be a good idea to allow choosing between POST and GET.
> 
> For example Twilio supports a simple HTTP POST operation to delivery SMS
> messages through their API:
> https://www.twilio.com/docs/api/rest/sending-messages
> 
> Many operators and service providers use a similar mechanism. Often the
> authentication is just a simple token which needs to be included in the
> request.
> 
> Best regards,
> Thomas
> 


More information about the keycloak-dev mailing list