July 2015 - keycloak-dev - Jboss List Archives

by Bill Burke

Was thinking about this more and I think it might be ok to have a session cookie that has all the initial information needed to restore the client session and restart the login without having to redirect back to the client. The session cookie would match up against the code query param that is passed around. This would probably be good enough protection. Only thing an attacker would be able to do is restart the login. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

8 years, 9 months

2
3
0 / 0

Is it possible to complete a login process with program ?

by Mai Zi

Hi, there, I am new in this domain so pls help me even my question looks too naive. What I want to do is as below: 1) Add a user with RESTful API . 2) get the token with direct access grant . All above will happen with program. We can add a user , but can not get the token . It seems the user can not login in . We missed something ? Is there any example code ? Thanks in advance. Mai

8 years, 9 months

2
1
0 / 0

Username Inconsistencies

by Scott Rossillo

When users have signed up via username and password, their username is their email address. However, if they first sign up via a social provider, they get a username of provider.email_address. Seems inconsistent. A user with a username and password who then logs in via a social provider retains just their email as the username. The username should never contain the provider, IMO. This is happening on 1.2.x. Has this been fixed in master? If so, is there an easy way to back port the fix? Thanks, Scott

8 years, 9 months

2
1
0 / 0

brute force improved

by Bill Burke

we finally have some unit tests for it (my bad). You can also unlock a locked user, or unlock all users too. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

8 years, 9 months

1
0
0 / 0

Service accounts - version 1 commited

by Marek Posolda

Few points to how it works now: - There is new boolean flag setServiceAccountsEnabled on ClientModel. That's the only model change - There is new tab "Service accounts" for confidential clients in admin console . Right now, service account authentication is available just for confidential clients, not bearer-only or public clients. The tab contains just one on/off switch for enable/disable service account authentication support. It's disabled by default. I think for the next release we can add the table with Authentication mechanisms for clients, so admin can choose for example that Client Credentials Grant is "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right now, the client authentication is available just through OAuth2 Client Credentials Grant (authentication with clientId + client secret) - When service account enabled for client "foo", new user "service-account-foo" is created . I've added the "service-account-" prefix just to make more visible that this is not normal user, but user dedicated to service account. The user has also attribute with client DB ID (It's really DB ID, not clientId) and the binding between client and user is through this attribute. Hence when admin renames clientId of this client or renames the username of service account user, the binding still works. The roles available to this user are used in the token dedicated to service account. - The existing TokenEndpoint is reused for service account authentication. Just new grantType "client_credentials" is added as per OAuth2 specs. - The token retrieved through service account has few additional attributes available in otherClaims(). Those are added by protocol mappers, which are created when service account authentication is enabled. Right now, it's just clientID, clientHost and client address (host and address are retrieved dynamically from ClientConnection used during auth request to TokenEndpoint). Should we have more info available in service account access token? - Sample app "service-account-example" added to the demo - Only missing piece for the 1.4 release seems to be docs unless you have additional feedback. WDYT? Marek

8 years, 9 months

2
5
0 / 0

Re: [keycloak-dev] Kerberos with IE does not work

by Michael Gerber

Yes, kerberos works fine. AuthorizeClientUtil.authorizeClient(authorizationHeader, formParams, event, realm); throws an UnauthorizedException exception because the authorization header contains Negotiate xxx instead of Basic xxx. Jira: https://issues.jboss.org/browse/KEYCLOAK-1595 Am 22. Juli 2015 um 14:23 schrieb Bill Burke <bburke(a)redhat.com>: So, the problem isn't that kerberos doesn't work, its that code to token doesn't work (neither does bearer)? On 7/22/2015 4:07 AM, Michael Gerber wrote: Hi all My kerberos configuration works fine with FireFox and Chrome, but it does not work with IE. It shows a prompt where the user has to enter a username and password. I can successfully get an access code, but I can not get an access token, because IE overwrites the Authorization header in the AJAX request. (see http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces...) I can fix this by adding document.execCommand('ClearAuthenticationCache', 'false'); above of var req = new XMLHttpRequest(); approximately at the line 374 in the keycloack.js file. Is there another solution for this problem? cheers Michael _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -- 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

8 years, 9 months

1
0
0 / 0

Kerberos with IE does not work

by Michael Gerber

Hi all My kerberos configuration works fine with FireFox and Chrome, but it does not work with IE. It shows a prompt where the user has to enter a username and password. I can successfully get an access code, but I can not get an access token, because IE overwrites the Authorization header in the AJAX request. (see http://stackoverflow.com/questions/28615850/internet-explorer-11-repl...) I can fix this by adding document.execCommand('ClearAuthenticationCache', 'false'); above of var req = new XMLHttpRequest(); approximately at the line 374 in the keycloack.js file. Is there another solution for this problem? cheers Michael

8 years, 9 months

3
2
0 / 0

multi tenant configuration with 1.3.1?

by Hipfinger Martin (BCC.ÖBB.TicketShop.MA)

Hi, we're running keycloak 1.1 with several overlays - in detail: - A new datasource per overlay /opt/keycloak/bin/jboss-cli.sh --commands="connect, data-source add --name=xxxDS --connection-url=jdbc:oracle:thin:@xxxxx:1522:xxxxx --jndi-name=java:jboss/datasources/xxxDS --driver-name=ojdbc --password=xxx --user-name=XXX" - A new auth-server entry /opt/keycloak/bin/jboss-cli.sh --commands="connect, /subsystem=keycloak/auth-server=xxx-server/:add(web-context=xxx, enabled=true)" - An own keycloak-server.json "connectionsJpa": { "default": { "dataSource": "java:jboss/datasources/xxxDS", "databaseSchema": "update" } } "connectionsInfinispan": { "default" : { "cacheContainer" : "java:jboss/infinispan/xxxKeycloak" } /opt/keycloak/bin/jboss-cli.sh --commands="connect, /subsystem=keycloak/auth-server=xxx-server:update-server-config(bytes-to-upload=/opt/keycloak/standalone/configuration/keycloak-server-xxx.json,overwrite=true)" This configuration isn't supported anymore with 1.3.1 - do you have any hint for me, how to achieve a similar config with 1.3.1? br, Martin

8 years, 9 months

2
1
0 / 0

Storage and migration issues

by Stian Thorgersen

Maintaining the storage providers are a incredible time sync and very error prone. On top of that we also have migration to deal with. It would be worth to improve this before we go to product. Why is storage so horrible?: * Multiple implementations - JPA + Mongo + Representations + Cache * Multiple database providers - every time we add anything it seems to break on at least one database * Migration - we have 4 different types of migration to deal with. Representations, JPA, Mongo and the generic one as well Not only do we spend a lot of time even adding the simplest thing to the model, but we also spend a lot of time getting it to work on all supported databases before release. This all made me think that we have to many options! I don't think users care how we store realm and client meta-data. They may care about users though. With that regards I think we should have a single realm store that is managed by Keycloak instead of supporting an external store. For users we'd still have the option to use JPA or Mongo, but that's a significantly simpler model, in fact I don't think we've barely touched it for a long time. We could also use the same managed store for users OOTB. For the realm store I'd like to use either a document store or a key-value store. Relational databases are just to much of a pain to get to work, migration is painful and it makes users expect that the database of their choice will work as well. Alternatives could be: * Cassandra * MongoDB * Plain files - we'd have a revision number of a realm or client and we'd replicate the details with Infinispan and store on all nodes * Infinispan store - Infinispan has built-in support for persisting data * DMR - in domain mode WildFly manages atomic updates to all nodes. Not sure if standalone.xml etc can deal with the amount of data we have though. * Continue storing in any store, but store a JSON blob for realms and clients. In relational database we'd have two tables, realms and clients, with an id, revision and blob With regards to migration I think we DO need to support updating from any version. In community this is an incredibly nice to have, but could also be more than that if a user is stuck on an old version and can't update to the intermediate version due to a bug. However, in product it's going to be required. Think about it a major release is supported for 8 years or something. We could end up with having 4 or more major versions out there at any given time. We can't expect a customer that's been on product v1 to upgrade to v2, then v3 to be able to upgrade to v4.

8 years, 9 months

3
4
0 / 0

Release status

by Stian Thorgersen

I'd like all changes in and issues fixed by the end of the week for 1.4 release. There's still quite a few issues remaining. Auth/required actions: ---------- There's quite a few issues outstanding in JIRA related to the new authentication SPIs: KEYCLOAK-1457 Auth flow for non-browser auth KEYCLOAK-1552 NPE if brute force detection enabled KEYCLOAK-1508 Re-Login fails after session timeout KEYCLOAK-1489 auth timeouts should restart flow KEYCLOAK-1481 reimplement AuthenticationManagerTest KEYCLOAK-1466 Find better way to propagate BruteForceProtector KEYCLOAK-1465 Cleanup obsolete auth code KEYCLOAK-1463 Need better UI for Terms and Conditions KEYCLOAK-1457 Auth flow for non-browser auth KEYCLOAK-1455 remove user.isTotp() usage KEYCLOAK-1450 Re-enable Brute Force Protection Also, what's the status with regards to: * Migration * Is brute force enabled? * Is the improvements with regards to login time outs added? * Do we need to polish the UI with regards to auth work? Service Accounts: ----------------- Marek told me service accounts and client credential grants is going to be ready later today. This won't include additional client authentication mechanisms. UXP improvements: ----------------- Still a few minor things left. I also need to review what's been done so far. The biggest issue left is updating tables to match the pattern from PatternFly, but that'll be delayed to 1.5 as it's a pretty big task. Database: --------- We have tests failing on some databases, as well as a few db related bugs. Other things: ------------- * KEYCLOAK-1539 Accessing secured resource should not return 200 OK when not authenticated - adapters redirect to login page even for json/xml requests. That doesn't make any sense. We should only redirect to login page if Accept header is */*, text/* or text/html. * KEYCLOAK-1472 WF8 Adapter: Preflight request is redirected for auth. - adapters redirect to login page for OPTIONS request. That doesn't make sense. We don't actually know the valid web origins for non-authenticated requests though. So what should we do? Is there anything else that needs to be done for 1.4 that's not in JIRA?

8 years, 9 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev July 2015