Groups on SSSD Federation provider
by Bruno Oliveira
Good morning,
Today I was chatting with Marek, about this issue[1]. It pretty much
relates to my previous thread about having read-only groups/roles.
In summary, groups are not tightly coupled to Federation providers.
So, to prevent read-only users from joining/leaving groups, at
joinGroup and leaveGroup methods, thrown an exception,
This is pretty much fine. However, the admin still can edit
the group and it's not possible to synchronize it back to SSSD —
everything is read-only.
That said, I was thinking if we really should synchronize user's
groups coming from SSSD or not. Because the chances of having a
group/role mismatch because someone decided to change its name is
high.
I can see two alternatives:
1. Never synchronize user's group from SSSD. We cannot synchronize it
back and I'm not sure how this information is relevant into our context.
For authentication with PAM, we don't need this information.
2. We keep it and permit the admin to change, but internally we preserve
the original name synchronized from SSSD. Maybe make the original name,
the id.
Thoughts?
[1] - https://issues.jboss.org/browse/KEYCLOAK-3904
--
abstractj
PGP: 0x84DC9914
9 years
Details on SAML Soap Binding support in Keycloak
by Rashmi Singh
We have a requirement to setup a SAML SP that sends SOAP request to the
keycloak IDP which returns the SOAP response to the SAML SP. We would like
to know if keycloak supports this? We came across something called as ECP
that probably provides this support but cant find details on how to
use/implement it. Could you provide us with some pointers on this?
Also, are there any sample SP that we can use to send SOAP requests to IDP?
If not, any pointers on how to set this all up?
9 years
ArtifactResolve with Keycloak IDP
by Rashmi Singh
We have a requirement to implement a scenario where SP can send a SOAP
request with ArtifactResolve to the keycloak IDP which in turn sends a SOAP
response with user attribute back to the SP.
The complete detailed scenario will be:
1) User sends login request
2) SP sends an HTTP Redirect to keycloak IDP
3) keycloak IDP authenticates the user
4) keycloak IDP sends Http redirect to AssertionConsumerService back to SP
5) SP sends SOAP request with ArtifactResolve to keycloak IDP
6) IDP sends SOAP Response with user attribute back to SP
The first four steps is what we pretty much understand. I am not sure how
to incorprate steps 5 and 6, that is: how to send SOAP request with
ArtifactResolve to keyclaok IDP.
what needs to be done on the keycloak side to support this and send back a
SOAP response to SP with user attributes? Could you provide any pointers
that would help us with this scenario
9 years, 1 month
Stateless using Keycloak Jetty Adapter gives NPE
by Laghuvaram, Raghu
I am planning to use Keycloak Jetty Adapter(9.2) as I felt that the Java Servlet Filter adapter can be used only with session and we cannot make use token-store as cookie with the Servlet Adapter. But I tried with Jetty Adapter I am getting NPE and I saw an open bug https://issues.jboss.org/browse/KEYCLOAK-2514. Is there any other workaround for this so that I can achieve stateless?
Thanks,
Raghu
________________________________
Notice: This communication may contain privileged and/or confidential information. If you are not the intended recipient, please notify the sender by email, and immediately delete the message and any attachments without copying or disclosing them. LB may, for any reason, intercept, access, use, and disclose any information that is communicated by or through, or which is stored on, its networks, applications, services, and devices.
9 years, 1 month
Federation Storage: read-only groups
by Bruno Oliveira
Good morning,
Today for SSSD Federation storage everything is read-only. This
is pretty much because we don't have any way to synchronize the changes
made at the admin console back to SSSD.
QE identified this bug[1], that kind of affects LDAP federation provider
in read-only mode too. Correct if I'm wrong, but in theory, if the federation
provider is read-only, people should not be able to edit groups or
roles.
Do we anything in the new API to prevent people from changing roles and
groups when the Federation provider is read-only?
[1] - https://issues.jboss.org/browse/KEYCLOAK-3904
--
abstractj
PGP: 0x84DC9914
9 years, 1 month
Suggestion and fix for e-Directory federation provider
by Tomas Tikovsky
Hello everyone,
im using e-directory federation ldap provider and came to this bug
KEYCLOAK-3099 <https://issues.jboss.org/browse/KEYCLOAK-3099> as i was
experiencing the same problem.
e-Directory sends guid attribute as byte[] so it needs to be declared as
binary the same way as its done for activeDirectory.
Sending simple diff to fix this issue if you consider this as helpfull.
Novell was acquired by microfocus and their product has been renamed to
netIQ eDirectory so i incorporated that change as well.
Another thing i noted were 2 incorrect attribute mappings in administration
console.
"username" -> "uid"
correct as long as users are enabled for linux (not default) otherwise cn.
So cn should work for more cases than uid.
"firstname" -> "cn"
wrong, should be "givenname"
Cheers
Tom
9 years, 1 month
Considering removing Mongo support
by Stian Thorgersen
All,
We are considering removing Mongo support from Keycloak in 3.x. The reasons
behind it is that there are a fair few issues in the current
implementation, especially around consistency due to lack of transaction
support in Mongo and often we update multiple documents. In many cases we
rely on transactions to rollback to prevent partial updates, but this
obviously doesn't work in Mongo.
With the fact that Mongo is already partially broken and the constant
maintenance involved we're considering removing it and rather focus purely
on the relational database back-end.
Another point to make is that we are not considering supporting Mongo in
the supported version of Keycloak (Red Hat Single Sign-On). So we are never
able to provide the same level of care and attention to it as we can for
relational databases.
If we do decide to remove it we would make sure we provide a seamless and
easy option to migrate from Mongo to a relational database!
I would like to gather some feedback from the community before doing
anything. So please vote on the following Doodle:
http://doodle.com/poll/nnimebpkx774ppus
Also, comments to this thread is more than welcome!
I'll end with a comment - Time spent by core developer on maintaining Mongo
could be better spent on awesome new features, testing and bug fixing!
9 years, 1 month
OpenID Connect client_Secret and Kubernetes
by Marc Boorshtein
Keycloak team,
A couple of months ago I started a thread on this list about if the
client_secret being shared across developers in kubernetes. The issue has
come up a few more times and a new ticket has been opened I thought you
would be interested in:
https://github.com/kubernetes/kubernetes/issues/37822
--
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
(703) 828-4902
Twitter - @mlbiam / @tremolosecurity
9 years, 1 month
