I'm developing a custom federation that communicates with my user repository via webservices. Probably this is a very strange scenario for a federation but that's the unique way that I have to communicate with the repository. My problem is that, as the webservices only exposes methods such as createUser and updateUser, I'm having problems with registrations and user profile updates because I'm not being able to do atomic calls to the webservice methods, with all the information that I need. As far as I know, from the properties file example and from the ldap federation source (probably I'm missing something) it seems that the federation api is intended to update and sync attribute by attribute (Keycloak <-> Federation). Am i wrong? Do you suggest another approach? Should I give up from having a federation that uses a webservice?

Thank you. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi, I think I'm in the right track now. I'm being able to call the webservice before commit. However, when the user is sucessfully created by the webservice, I need to update my local user to add a property with the external user id. How can I do that in the same transaction? I'm trying to set the property on the managed delegate user model, but it has no effect. Thank you! On 9 Dec 2015 18:39, "Marek Posolda" <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: On 09/12/15 19:33, Jorge M. wrote: > > I'm developing a custom federation that communicates with my user > repository via webservices. > Probably this is a very strange scenario for a federation but > that's the unique way that I have to communicate with the repository. > > My problem is that, as the webservices only exposes methods such > as createUser and updateUser, I'm having problems with > registrations and user profile updates because I'm not being able > to do atomic calls to the webservice methods, with all the > information that I need. > > As far as I know, from the properties file example and from the > ldap federation source (probably I'm missing something) it seems > that the federation api is intended to update and sync attribute > by attribute (Keycloak <-> Federation). > Am i wrong? Do you suggest another approach? Should I give up > from having a federation that uses a webservice? > You can use "transaction wrapper", which will allow you to store all the updates to user locally, but send the UPDATE request to your webservice later at transaction commit time. You may need to create custom transaction and enlist it with Keycloak TransactionManager. This is what we have for LDAP federation provider right now. See TxAwareLDAPUserModelDelegate. Marek > > Thank you. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

I think what we can possibly do is: 1) Improve KeycloakTransactionManager to allow enlist with "priority" . Instead of methods: void enlist(KeycloakTransaction transaction); void enlistAfterCompletion(KeycloakTransaction transaction); we will have single method: void enlist(KeycloakTransaction transaction, int priority); By default, JPA will enlist transaction with priority 10 and infinispan with priority 20 or something like that. This change will allow to enlist your transaction in your FederationProvider with exact priority. So you can choose whether the commit will happen before JPA commit, or after JPA commit or even after infinispan commit etc.

2) Make TxAwareLDAPUserModelDelegate class more generic and reusable for other federation providers

Marek On 11/12/15 10:50, Vlastimil Elias wrote: > Hi, > > I use similar approach and problem is (at least I think) that local > DB transaction is already commited when our code runs. It has two > negative effects: > - if remote service call is successful you are not able to write > anything locally as Jorge mentioned > - if remote service call fails local DB record is commited already > and it is hard to implement correct error handling > > So I think User Federation SPI should be extended by exact method > which allows atomic call of backend during user creation or update > before local transaction is commited. I already created issue for it > but not resolved yet https://issues.jboss.org/browse/KEYCLOAK-1075 > > Vlastimil > > On 10.12.2015 18:49, Jorge M. wrote: >> >> Hi, >> >> I think I'm in the right track now. I'm being able to call the >> webservice before commit. However, when the user is sucessfully >> created by the webservice, I need to update my local user to add a >> property with the external user id. How can I do that in the same >> transaction? >> I'm trying to set the property on the managed delegate user model, >> but it has no effect. >> >> Thank you! >> >> On 9 Dec 2015 18:39, "Marek Posolda" <mposolda(a)redhat.com&gt; wrote: >> >> On 09/12/15 19:33, Jorge M. wrote: >>> >>> I'm developing a custom federation that communicates with my >>> user repository via webservices. >>> Probably this is a very strange scenario for a federation but >>> that's the unique way that I have to communicate with the >>> repository. >>> >>> My problem is that, as the webservices only exposes methods >>> such as createUser and updateUser, I'm having problems with >>> registrations and user profile updates because I'm not being >>> able to do atomic calls to the webservice methods, with all the >>> information that I need. >>> >>> As far as I know, from the properties file example and from the >>> ldap federation source (probably I'm missing something) it >>> seems that the federation api is intended to update and sync >>> attribute by attribute (Keycloak <-> Federation). >>> Am i wrong? Do you suggest another approach? Should I give up >>> from having a federation that uses a webservice? >>> >> You can use "transaction wrapper", which will allow you to store >> all the updates to user locally, but send the UPDATE request to >> your webservice later at transaction commit time. You may need >> to create custom transaction and enlist it with Keycloak >> TransactionManager. >> >> This is what we have for LDAP federation provider right now. See >> TxAwareLDAPUserModelDelegate. >> >> Marek >>> >>> Thank you. >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Vlastimil Elias > Principal Software Engineer > Developer Portal Engineering Team > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

I agree. I think that could solve these issues. Is that something that can go on a near release? Thank yoy On 11 Dec 2015 12:15, "Vlastimil Elias" <velias(a)redhat.com <mailto:velias@redhat.com>> wrote: On 11.12.2015 12:19, Marek Posolda wrote: > I think what we can possibly do is: > > 1) Improve KeycloakTransactionManager to allow enlist with > "priority" . Instead of methods: > > void enlist(KeycloakTransaction transaction); > void enlistAfterCompletion(KeycloakTransaction transaction); > > we will have single method: > > void enlist(KeycloakTransaction transaction, int priority); > > By default, JPA will enlist transaction with priority 10 and > infinispan with priority 20 or something like that. > > This change will allow to enlist your transaction in your > FederationProvider with exact priority. So you can choose whether > the commit will happen before JPA commit, or after JPA commit or > even after infinispan commit etc. > +1, this may help to resolve current problems > 2) Make TxAwareLDAPUserModelDelegate class more generic and > reusable for other federation providers may also help, but point 1 with correct documentation is main what we have to do Thanks Vlastimil > > Marek > > On 11/12/15 10:50, Vlastimil Elias wrote: >> Hi, >> >> I use similar approach and problem is (at least I think) that >> local DB transaction is already commited when our code runs. It >> has two negative effects: >> - if remote service call is successful you are not able to write >> anything locally as Jorge mentioned >> - if remote service call fails local DB record is commited >> already and it is hard to implement correct error handling >> >> So I think User Federation SPI should be extended by exact >> method which allows atomic call of backend during user creation >> or update before local transaction is commited. I already >> created issue for it but not resolved yet >> https://issues.jboss.org/browse/KEYCLOAK-1075 >> >> Vlastimil >> >> On 10.12.2015 18:49, Jorge M. wrote: >>> >>> Hi, >>> >>> I think I'm in the right track now. I'm being able to call the >>> webservice before commit. However, when the user is sucessfully >>> created by the webservice, I need to update my local user to >>> add a property with the external user id. How can I do that in >>> the same transaction? >>> I'm trying to set the property on the managed delegate user >>> model, but it has no effect. >>> >>> Thank you! >>> >>> On 9 Dec 2015 18:39, "Marek Posolda" <mposolda(a)redhat.com >>> <mailto:mposolda@redhat.com>> wrote: >>> >>> On 09/12/15 19:33, Jorge M. wrote: >>>> >>>> I'm developing a custom federation that communicates with >>>> my user repository via webservices. >>>> Probably this is a very strange scenario for a federation >>>> but that's the unique way that I have to communicate with >>>> the repository. >>>> >>>> My problem is that, as the webservices only exposes >>>> methods such as createUser and updateUser, I'm having >>>> problems with registrations and user profile updates >>>> because I'm not being able to do atomic calls to the >>>> webservice methods, with all the information that I need. >>>> >>>> As far as I know, from the properties file example and >>>> from the ldap federation source (probably I'm missing >>>> something) it seems that the federation api is intended to >>>> update and sync attribute by attribute (Keycloak <-> >>>> Federation). >>>> Am i wrong? Do you suggest another approach? Should I give >>>> up from having a federation that uses a webservice? >>>> >>> You can use "transaction wrapper", which will allow you to >>> store all the updates to user locally, but send the UPDATE >>> request to your webservice later at transaction commit >>> time. You may need to create custom transaction and enlist >>> it with Keycloak TransactionManager. >>> >>> This is what we have for LDAP federation provider right >>> now. See TxAwareLDAPUserModelDelegate. >>> >>> Marek >>>> >>>> Thank you. >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> <mailto:keycloak-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> Developer Portal Engineering Team >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Vlastimil Elias Principal Software Engineer Developer Portal Engineering Team _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev

I guess in certain situations this can be helpful. It doesn't solve the problem though so we need something smarter at some point, but we don't have the time to do it right now so would have to be for 2.x. On 14 December 2015 at 21:21, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > I think yes. It should be quite easy to change the signature of > KeycloakTransactionManager methods. Just waiting if other team members > agree and then we can possibly change fix version of > https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do it for this > release. > > Marek > > > On 14/12/15 17:15, Jorge M. wrote: > > I agree. I think that could solve these issues. Is that something that > can go on a near release? > > Thank yoy > On 11 Dec 2015 12:15, "Vlastimil Elias" <velias(a)redhat.com&gt; wrote: > >> >> >> On 11.12.2015 12:19, Marek Posolda wrote: >> >> I think what we can possibly do is: >> >> 1) Improve KeycloakTransactionManager to allow enlist with "priority" . >> Instead of methods: >> >> void enlist(KeycloakTransaction transaction); >> void enlistAfterCompletion(KeycloakTransaction transaction); >> >> we will have single method: >> >> void enlist(KeycloakTransaction transaction, int priority); >> >> By default, JPA will enlist transaction with priority 10 and infinispan >> with priority 20 or something like that. >> >> This change will allow to enlist your transaction in your >> FederationProvider with exact priority. So you can choose whether the >> commit will happen before JPA commit, or after JPA commit or even after >> infinispan commit etc. >> >> >> +1, this may help to resolve current problems >> >> 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable for >> other federation providers >> >> >> may also help, but point 1 with correct documentation is main what we >> have to do >> >> Thanks >> >> Vlastimil >> >> >> Marek >> >> On 11/12/15 10:50, Vlastimil Elias wrote: >> >> Hi, >> >> I use similar approach and problem is (at least I think) that local DB >> transaction is already commited when our code runs. It has two negative >> effects: >> - if remote service call is successful you are not able to write >> anything locally as Jorge mentioned >> - if remote service call fails local DB record is commited already and >> it is hard to implement correct error handling >> >> So I think User Federation SPI should be extended by exact method which >> allows atomic call of backend during user creation or update before local >> transaction is commited. I already created issue for it but not resolved >> yet https://issues.jboss.org/browse/KEYCLOAK-1075 >> >> Vlastimil >> >> On 10.12.2015 18:49, Jorge M. wrote: >> >> Hi, >> >> I think I'm in the right track now. I'm being able to call the >> webservice before commit. However, when the user is sucessfully created by >> the webservice, I need to update my local user to add a property with the >> external user id. How can I do that in the same transaction? >> I'm trying to set the property on the managed delegate user model, but >> it has no effect. >> >> Thank you! >> On 9 Dec 2015 18:39, "Marek Posolda" <mposolda(a)redhat.com&gt; wrote: >> >>> On 09/12/15 19:33, Jorge M. wrote: >>> >>> I'm developing a custom federation that communicates with my user >>> repository via webservices. >>> Probably this is a very strange scenario for a federation but that's >>> the unique way that I have to communicate with the repository. >>> >>> My problem is that, as the webservices only exposes methods such as >>> createUser and updateUser, I'm having problems with registrations and user >>> profile updates because I'm not being able to do atomic calls to the >>> webservice methods, with all the information that I need. >>> >>> As far as I know, from the properties file example and from the ldap >>> federation source (probably I'm missing something) it seems that the >>> federation api is intended to update and sync attribute by attribute >>> (Keycloak <-> Federation). >>> Am i wrong? Do you suggest another approach? Should I give up from >>> having a federation that uses a webservice? >>> >>> You can use "transaction wrapper", which will allow you to store all >>> the updates to user locally, but send the UPDATE request to your webservice >>> later at transaction commit time. You may need to create custom transaction >>> and enlist it with Keycloak TransactionManager. >>> >>> This is what we have for LDAP federation provider right now. See >>> TxAwareLDAPUserModelDelegate. >>> >>> Marek >>> >>> Thank you. >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> Developer Portal Engineering Team >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> Developer Portal Engineering Team >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

On 22/12/15 11:43, Jorge M. wrote: Hi, "I think I'm in the right track now. I'm being able to call the webservice before commit. However, when the user is sucessfully created by the webservice, I need to update my local user to add a property with the external user id. How can I do that in the same transaction? I'm trying to set the property on the managed delegate user model, but it has no effect." Is there any workaround for this? Basically, after the webservice call (I'm doing the job with an approach based on TxAwareLDAPUserModelDelegate) I need to get the previously saved userStorage user, set an attribute and save it again. At UserProvider interface I can't see any update method. Yes, there is no any update method. It's because data of UserModel are automatically persistent and attached with DB. For example if you call: UserModel john = session.users().getUserByUsername("john"); The "john" instance is persistent. So then if you call: john.setFirstName("Johnnn"); the firstName is updated automatically in DB. No reason to call any additional update method. So if you are really able to call your webservice before commit, then you can just do something like: Object wsOutput = callYourWebService(...); john.setFirstName(wsOutput.getSomethingFromWSOutput); john.setAttribute("foo", wsOutput.getSomethingElseFromWSOutput); and it should work. If it doesn't work, then you're probably calling your web service after DB commit (this is what TxAwareLDAPUserModelDelegate is also doing btv. LDAP commit is send after DB commit). We will likely improve that for 1.8 by allow enlist transaction with priorities, which will allow to specify if your federationProvider commit should be called before or after JPA commit (See my previous email). Marek Thanks 2015-12-17 8:50 GMT+00:00 Stian Thorgersen <sthorger(a)redhat.com&gt;: > I guess in certain situations this can be helpful. It doesn't solve the > problem though so we need something smarter at some point, but we don't > have the time to do it right now so would have to be for 2.x. > > On 14 December 2015 at 21:21, Marek Posolda < <mposolda(a)redhat.com&gt; > mposolda(a)redhat.com&gt; wrote: > >> I think yes. It should be quite easy to change the signature of >> KeycloakTransactionManager methods. Just waiting if other team members >> agree and then we can possibly change fix version of >> <https://issues.jboss.org/browse/KEYCLOAK-1075> >> https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do it for this >> release. >> >> Marek >> >> >> On 14/12/15 17:15, Jorge M. wrote: >> >> I agree. I think that could solve these issues. Is that something that >> can go on a near release? >> >> Thank yoy >> On 11 Dec 2015 12:15, "Vlastimil Elias" < <velias(a)redhat.com&gt; >> velias(a)redhat.com&gt; wrote: >> >>> >>> >>> On 11.12.2015 12:19, Marek Posolda wrote: >>> >>> I think what we can possibly do is: >>> >>> 1) Improve KeycloakTransactionManager to allow enlist with "priority" . >>> Instead of methods: >>> >>> void enlist(KeycloakTransaction transaction); >>> void enlistAfterCompletion(KeycloakTransaction transaction); >>> >>> we will have single method: >>> >>> void enlist(KeycloakTransaction transaction, int priority); >>> >>> By default, JPA will enlist transaction with priority 10 and infinispan >>> with priority 20 or something like that. >>> >>> This change will allow to enlist your transaction in your >>> FederationProvider with exact priority. So you can choose whether the >>> commit will happen before JPA commit, or after JPA commit or even after >>> infinispan commit etc. >>> >>> >>> +1, this may help to resolve current problems >>> >>> 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable >>> for other federation providers >>> >>> >>> may also help, but point 1 with correct documentation is main what we >>> have to do >>> >>> Thanks >>> >>> Vlastimil >>> >>> >>> Marek >>> >>> On 11/12/15 10:50, Vlastimil Elias wrote: >>> >>> Hi, >>> >>> I use similar approach and problem is (at least I think) that local DB >>> transaction is already commited when our code runs. It has two negative >>> effects: >>> - if remote service call is successful you are not able to write >>> anything locally as Jorge mentioned >>> - if remote service call fails local DB record is commited already and >>> it is hard to implement correct error handling >>> >>> So I think User Federation SPI should be extended by exact method which >>> allows atomic call of backend during user creation or update before local >>> transaction is commited. I already created issue for it but not resolved >>> yet <https://issues.jboss.org/browse/KEYCLOAK-1075> >>> https://issues.jboss.org/browse/KEYCLOAK-1075 >>> >>> Vlastimil >>> >>> On 10.12.2015 18:49, Jorge M. wrote: >>> >>> Hi, >>> >>> I think I'm in the right track now. I'm being able to call the >>> webservice before commit. However, when the user is sucessfully created by >>> the webservice, I need to update my local user to add a property with the >>> external user id. How can I do that in the same transaction? >>> I'm trying to set the property on the managed delegate user model, but >>> it has no effect. >>> >>> Thank you! >>> On 9 Dec 2015 18:39, "Marek Posolda" < <mposolda(a)redhat.com&gt; >>> mposolda(a)redhat.com&gt; wrote: >>> >>>> On 09/12/15 19:33, Jorge M. wrote: >>>> >>>> I'm developing a custom federation that communicates with my user >>>> repository via webservices. >>>> Probably this is a very strange scenario for a federation but that's >>>> the unique way that I have to communicate with the repository. >>>> >>>> My problem is that, as the webservices only exposes methods such as >>>> createUser and updateUser, I'm having problems with registrations and user >>>> profile updates because I'm not being able to do atomic calls to the >>>> webservice methods, with all the information that I need. >>>> >>>> As far as I know, from the properties file example and from the ldap >>>> federation source (probably I'm missing something) it seems that the >>>> federation api is intended to update and sync attribute by attribute >>>> (Keycloak <-> Federation). >>>> Am i wrong? Do you suggest another approach? Should I give up from >>>> having a federation that uses a webservice? >>>> >>>> You can use "transaction wrapper", which will allow you to store all >>>> the updates to user locally, but send the UPDATE request to your webservice >>>> later at transaction commit time. You may need to create custom transaction >>>> and enlist it with Keycloak TransactionManager. >>>> >>>> This is what we have for LDAP federation provider right now. See >>>> TxAwareLDAPUserModelDelegate. >>>> >>>> Marek >>>> >>>> Thank you. >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> -- >>> Vlastimil Elias >>> Principal Software Engineer >>> Developer Portal Engineering Team >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> -- >>> Vlastimil Elias >>> Principal Software Engineer >>> Developer Portal Engineering Team >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >