[keycloak-dev] simplfying client creation

[Thomas Raehalme]

On Dec 22, 2015 09:35, "Stian Thorgersen" <sthorger at redhat.com> wrote:
> On 21 December 2015 at 16:31, Bill Burke <bburke at redhat.com> wrote:
>>
>> The last phase of client templates would be to allow defining
>> configuration items in the client template that the client inherits.  I
>> was going to implement it as an either or.  There will be a switch
>> "Inherit Template Configuration"  If this is off, then config items are
>> taken from the client, otherwise they are taken from the template.
>> There would be no mix and match.
>
>
> What's the point in that? I can't see anyone wanting to create multiple
clients with the same config.

I think it depends how you would like to implement multitenancy. With a
single realm, client for each tenant, wouldn't it simplify configuration a
great deal?

Best regards,
Thomas

>
>>
>>
>> FYI, I"m not sure I'll be able to finish this prior to our deadline of
>> early January.  There's still a lot of JIRAs to do beyond this.
>>
>> This week though, I think I want to rework and simplify client creation
>> a bit more.  Create client on the admin console would only require must
>> needed config attributes:
>>
>> OIDC:
>> Client ID
>> Root URL
>> Choose Client Template if wanted
>>
>> These would be the defaults:
>> * Access type: public (pretty much covers any use)
>> * enabled true
>> * Redirect URIs would default to Root/*
>> * Standard Flow true
>> * Direct Grants false
>> * Service Accounts false
>
>
>>
>> SAML:
>> Client Entity ID:
>> SAML SP Endpoint (not required, can make it more fine grained)
>> Choose client template if wanted
>>
>> * Sign Docs: true
>> * Sign Assertions: false
>> * Client Signature Required: true
>> * Force POST BInding true
>> * Front Channel logout: true
>> * Force Name ID Format: false
>> * Name ID Format username
>> * Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs
>> * certs would be generated by default
>
>
> So you are proposing that create client and edit client screens are
different? IMO that's not good. Instead we should use tabs to split the
settings into multiple sections. From what you are proposing above I see
that most folks would have to first create the client then immediately edit
the client afterwards.
>
> I'd like refactoring and UX changes to be discussed properly prior to
doing them.
>
>>
>>
>> I'm also going to add a method to LoginProtocolFactory:
>>
>> setupDefaults(ClientModel).  When a client is created, this method would
>> be called, then the defaults would be overriden if they are set in the
>> ClientRepresentation.  Right now, all this default logic is in the admin
>> console and I don't think it should be there.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151222/2b1968cd/attachment.html