Alfresco Integration
by Yunus ÖNCEL
Hello;
I have a short question.
It is possible ? can i integration alfresco authentication system with
Keycloak?
Alfresco want use mod_auth_cas. do work keycloak with mod_auth_cas ?
Thank you
Sorry for my English :)
10 years
Re: [keycloak-dev] Opinion on how secret the OIDC "client secret" should be?
by Marc Boorshtein
Reposting on Eric's behalf
On Sep 14, 2016 2:54 PM, "Eric Chiang" <eric.chiang(a)coreos.com> wrote:
> Thanks Marc for the cc,
>
> Just to give some background for the reasoning behind this.
>
> Today the Kubernetes API server trusts ID Tokens issued to a single
> client. Refreshing a token requires a client_secret, hence the flags Marc
> provided in his example. Though we don't have official recommendations
> about what the properties of the client passed in those flags should be
> there's two obvious ways of going about this.
>
> 1) Have each kubectl share a client secret. Some authorization servers
> provide mechanisms for declaring "public clients" to imposes restrictions
> on its capabilities. For example Google, when it assumes client_secrets
> aren't secret, restricts the redirect URLs for embedded apps to only
> localhost and a magic OOB, doesn't let it do incremental authorization,
> etc. Though as Marc noted this may have unintended consequences with
> providers who assume this doesn't happen.
>
> 2) Another option is for kubectl to utilize the "azp" claim in the ID
> Token[0], which allows clients to request ID Tokens on behalf of other
> clients. This means each kubectl gets its own client_id and client_secret,
> with each one requesting ID Tokens minted for a common client_id. However
> that capability isn't generally supported by OIDC providers, though Google
> does[1]. This is probably a more secure option, but the actual
> implementations differ so widely that it becomes hard to make a general
> statement.
>
> We'd be interested in knowing if either of these methods raise red flags
> when combined with keycloak.
>
> Eric
>
> [0] https://openid.net/specs/openid-connect-core-1_0.html#IDToken
> [1] https://developers.google.com/identity/protocols/CrossClientAuth
>
>
>
> On Wed, Sep 14, 2016 at 10:16 AM, Marc Boorshtein <marc.boorshtein@
> tremolosecurity.com> wrote:
>
>> KC Team,
>>
>> Eric Chiang from CoreOS (cc'd on this email) and I have been talking
>> on the Kubernetes sig-auth slack channel about how secret the "client
>> secret" in OIDC should be. The context for the question is that
>> Kubernetes' OIDC implementation uses the id_token as the bearer token
>> (as opposed to the access_token) to avoid a round trip. Since the
>> id_token should be short lived the question of how to get a new one
>> using a refresh_token. The current solution is to give kubectl the
>> refresh_token, the idp discovery url and the client id and secret:
>>
>> kubectl config set-credentials --auth-provider=oidc
>> kubectl config set-credentials --auth-provider-args=idp-issuer-url=(
>> issuer url )
>> kubectl config set-credentials --auth-provider-args=client_id=( your
>> client id )
>> kubectl config set-credentials --auth-provider-args=client_secret=(
>> your client secret )
>> kubectl config set-credentials --auth-provider-args=refresh-token=(
>> your refresh token )
>>
>> This way kubectl can get a new id_token once the possessed one
>> expires. The question becomes does giving the client_secret directly
>> to users become a security issue since its now a shared credential?
>>
>> Some issues I see are:
>> 1. Rotation becomes harder - how many people have this?
>> 2. While you can't generate an access_token with just this secret,
>> you CAN impersonate an RP so if your are monitoring which RPs are
>> making requests an attacker could generate excessive requests for a
>> single RP even if those requests fail
>> 3. Since most IdPs will generate some kind of back-end record for a
>> request if you have the client id and secret you could more easily do
>> a DoS attack by flooding the server with authenticated requestes for
>> authentication
>>
>> What are your thoughts? Google provides an example asserting that the
>> client secret ISN'T secret (reading through it I think the example
>> contradicts its self)
>> https://developers.google.com/api-client-library/python/auth
>> /installed-app
>>
>> Thanks
>>
>>
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorshtein(a)tremolosecurity.com
>> Twitter - @mlbiam / @tremolosecurity
>>
>
>
10 years
Ideas for the JavaOne's KeyCloak Hackengarten
by Sebastien Blanc
Hi !
Next week I will be at JavaOne, during the week I will have the privilege
to lead for an afternoon the hackergarten area. For sure, I would like to
bring up the KeyCloak project (along with Forge and maybe Swarm).
For those who don't know what an hackergarten is : http://hackergarten.net/
So, do we have any JIRAs, docs , tests missing that would fit for a 3 hours
hacker session ?
My own ideas :
- Work on the Keycloak Forge Addon : Create Clients from Forge etc ...
- Start exploring a Keycloak Go Adapter
- Polish Java Adapter Documentation
I wait for your ideas !
Sebi
10 years
Integration tests for FreeIPA
by Bruno Oliveira
Ahoy, this week I will start to look at the integration tests for
FreeIPA/SSSD with Ilya from QE. He already started some work here[1].
The tricky part for me is to spin up a FreeIPA server on Travis CI.
For those not familiar with this environment, to run the
integration tests, freeipa-server must be installed/configured.
Unfortunately, Ubuntu Precise (the distro running on Travis)
have only freeipa-client and python-freeipa[2].
Some ideas to make this happen:
1. Do nothing and let people run the integration tests locally. This is not awesome.
2. Spin up a FreeIPA docker instance on Travis before the build, plus
install and configure a freeipa-client. The downside is: more steps,
more slowness on Travis.
3. Move the CI to our own server and have FreeIPA installed and
configured.
Ideas?
[1] - https://github.com/abstractj/keycloak/commit/534569a9b6082a9674a33149519b...
[2] - https://launchpad.net/ubuntu/precise/+source/freeipa
--
abstractj
PGP: 0x84DC9914
10 years
Keycloak Integration TestSuite FAILURE
by Maurício Giacomini Penteado
Hello everybody.
All my attempts to build keycloak result in the same errors:
Keycloak Integration TestSuite FAILURE
Failed tests:
JaxrsFilterTest.testCors:286 expected:<200> but was:<403>
JaxrsFilterTest.testRelativeUriAndPublicKey:172 expected:<500> but was:<401>
Tests in error:
JaxrsBasicAuthTest.testBasic:141 » ClientError HTTP 403 Forbidden
JaxrsFilterTest.testBasic:141 » ClientError HTTP 403 Forbidden
JaxrsFilterTest.testPushNotBefore:314 » ClientError HTTP 403 Forbidden
JaxrsFilterTest.testResourceRoleMappings:236 » ClientError HTTP 403 Forbidden
Tests run: 414, Failures: 2, Errors: 4, Skipped: 32
If somebody has an idea about what happens, please let me know!
Kind regards,
Maurício.
10 years
Allow multiple users with the same email
by Tomas Groth Christensen
Hi,
I'm involved in a project where we use Keycloak as Identity Broker, and
so far we've been very happy with Keycloak, and implemented a few SPIs
to do some special things, but now we've hit a snag...
In our setup we have many clients using the Identity Broker which then
again has many Identity Providers from which the user can chose one to
use for login.
Our problem is that the same user (using one email address) can exist
in 2 or more Identity Providers, and we do not want to link these
accounts. The reason for not linking the accounts is that the user can
be given special privileges in clients, based on which Identity
Provider the user comes from. These privileges should not be carried
over from one Identity Providers user to another since the same user
might be an administrator when coming the one Identity Provider and a
common user when coming from a different Identity Provider.
So, is it possible to allow multiple users to have the same email
address? Looking at the source code there are checks for duplicated
user-emails in most places where users are created... Could a solution
be to implement a custom authenticator that replaces
IdpCreateUserIfUniqueAuthenticator which does not check for duplicated
emails, or are there database constraints that will prohibit this?
An alternative solution could perhaps be a custom authenticator that
simply deletes existing users with the same email address?
I hope you can give me some pointer on how to proceed...
--
Best regards,
Tomas Groth Christensen
Softwaredeveloper
Danish Maritime Authority
10 years
Opinion on how secret the OIDC "client secret" should be?
by Marc Boorshtein
KC Team,
Eric Chiang from CoreOS (cc'd on this email) and I have been talking
on the Kubernetes sig-auth slack channel about how secret the "client
secret" in OIDC should be. The context for the question is that
Kubernetes' OIDC implementation uses the id_token as the bearer token
(as opposed to the access_token) to avoid a round trip. Since the
id_token should be short lived the question of how to get a new one
using a refresh_token. The current solution is to give kubectl the
refresh_token, the idp discovery url and the client id and secret:
kubectl config set-credentials --auth-provider=oidc
kubectl config set-credentials --auth-provider-args=idp-issuer-url=(
issuer url )
kubectl config set-credentials --auth-provider-args=client_id=( your client id )
kubectl config set-credentials --auth-provider-args=client_secret=(
your client secret )
kubectl config set-credentials --auth-provider-args=refresh-token=(
your refresh token )
This way kubectl can get a new id_token once the possessed one
expires. The question becomes does giving the client_secret directly
to users become a security issue since its now a shared credential?
Some issues I see are:
1. Rotation becomes harder - how many people have this?
2. While you can't generate an access_token with just this secret,
you CAN impersonate an RP so if your are monitoring which RPs are
making requests an attacker could generate excessive requests for a
single RP even if those requests fail
3. Since most IdPs will generate some kind of back-end record for a
request if you have the client id and secret you could more easily do
a DoS attack by flooding the server with authenticated requestes for
authentication
What are your thoughts? Google provides an example asserting that the
client secret ISN'T secret (reading through it I think the example
contradicts its self)
https://developers.google.com/api-client-library/python/auth/installed-app
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
Twitter - @mlbiam / @tremolosecurity
10 years
LDAP setup for demonstration purposes
by Stian Thorgersen
I'd like to have a simple way to demo LDAP and Kerberos support. To that
end we should add a Vagrant setup with the following:
* Keycloak server
* MySQL or Postgres
* FreeIPA
* Workstation with Kerberos authentication (needs X and Firefox installed)
The Keycloak server should already be configured to use the FreeIPA server
as a user federation provider (using LDAP and Kerberos). The workstation
can be co-located with FreeIPA server if it makes things much simpler, but
it should be possible to login to the workstation with Kerberos. Firefox
should be pre-configured for Kerberos to work both on Keycloak login and
FreeIPA admin console.
I want a proper database and a web based client for the database so it's
simple to inspect the database.
Bruno has already volunteered to look into this, but first we should make
sure this is the setup we'd like to be able to showcase.
10 years
Supporting date/time of consent in the model
by Geir Ole Hiåsen Stevning
Hi!
We have a use case where we need to know the time for when an End-User has
given consent. Would it be possible to add a Date-like field in either
UserConsentProtocolMapperEntity, UserConsentRoleEntity or
UserConsentEntity, as we are using the JPA provider.
Furthermore, propagate this field in the corresponding DTO-like objects as
UserConsentModel etc. Doing this will probably mean that additional
providers will need to populate the field, i.e. mongo.
Is this something that you guys think is a good idea? I would be able to
create a PR if you would like that.
--
Geir Ole H. Stevning
10 years
