8:35 a.m.
On 21 December 2015 at 16:31, Bill Burke <bburke(a)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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev