[JBoss JIRA] (ELY-457) SASL SAML Authentication Mechanism
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-457:
--------------------------------
[~dlofthouse] By specification SAML SaslServer should wait and receive HTTP call from IdP - it looks like it needs to be integrated with undertow somehow...
Do we have some plan how to handle similar things already? Or should I postpone this until F2F too?
The SaslServer should work by following way:
* sasl server receive initial-response (domain name of IdP)
* sasl server sends authentication-request
* sasl server receive "="
* *! sasl server waits for authentication statement from IdP over HTTP !*
* when received, sasl server sends completion message to client
> SASL SAML Authentication Mechanism
> ----------------------------------
>
> Key: ELY-457
> URL: https://issues.jboss.org/browse/ELY-457
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> https://tools.ietf.org/html/rfc6595
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JGRP-2237) The single node in the cluster not become a coordinator after coordinator leave.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2237?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2237:
--------------------------------
Have you tried this with the config I attached (test.xml)? And please use the latest 4.0.8 to test; this is what I used and I never hit a problem.
Your log shows the member waited for 30s which is impossible as {{GMS.timeout}} is 3s in the config you attached! So either you used the wrong config, or attached the wrong config!
> The single node in the cluster not become a coordinator after coordinator leave.
> --------------------------------------------------------------------------------
>
> Key: JGRP-2237
> URL: https://issues.jboss.org/browse/JGRP-2237
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.2, 4.0.8
> Reporter: kfir avraham
> Assignee: Bela Ban
> Priority: Minor
> Attachments: test.xml
>
>
> I got cluster with 2 members, sometimes when the first node (coordinator) leave the cluster the second one is not become a coordinator.
> When the first one is rejoin, he could not determine coordinator and select new one from the nodes list.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (JGRP-2238) KUBE_PING should read old env variables and should warn
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2238?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2238:
---------------------------
Fix Version/s: 4.0.9
> KUBE_PING should read old env variables and should warn
> -------------------------------------------------------
>
> Key: JGRP-2238
> URL: https://issues.jboss.org/browse/JGRP-2238
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 4.0.9
>
>
> While I was upgrading Infinispan cluster on docker, I realised I was using old environment properties. These were neither read nor was any WARN messages being reported.
> The code should read the current properties and if not present should try to read the old ones and assign them. Then, we should check if both new and old properties are in use and we should also check if only old ones in use. Both scenarios should warn the user.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month