Improve first login with identity provider
by Stian Thorgersen
We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not!
The mechanism to detect existing accounts should include:
* Username
* Email
* Firstname and lastname
This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following:
* Cancel
* Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links)
* Continue - only if existing account is found by firstname and lastname
For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email.
We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile.
Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time.
With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider.
It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5.
8 years, 9 months
Re: [keycloak-dev] [wildfly-dev] Using feature packs for custom distributions
by Marko Strukelj
Thanks Bob for confirming that skipping optionals should work.
My initial attempts at that were still pulling in the whole world, but I found it was due to a tiny bug in the tool I used that skipped some optionals but not all of them. Things look much more promising now ...
----- Original Message -----
> >> For our use-case this would also be addressed by wildfly providing a
> >> feature-pack definition that’s somewhere between servlet-feature-pack and
> >> full-feature-pack - as long as it contains datasources support, and jaxrs
> >> support …
> >
> > I think this is a good idea, to skip optional deps.
>
> This is what wildfly-swarm does.
>
> We consume the WF feature-packs, but only solve the tree from a few root
> module.xml’s to extract only the subset we need.
>
> And if it’s optional=“true”, we pretend we don’t need it. That helps a lot.
>
> Also, as soon as something pulls in weld, you’re pretty screwed, since weld
> then depends on most everything else, many times non-optionally.
>
> -Bob
>
>
>
> >
> >>
> >> Another thing is provisioning of feature packs, which I address in another
> >> email.
> >>
> >>
> >> - marko
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
8 years, 9 months
RealmRep needs to be human craftable?
by Bill Burke
In implementing import/export for authentication flows, i realized that
it is not very human craftable. That is, not easy for a human to create
a json rep of authentication flows.
Do we still need to support that case?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8 years, 9 months
Error when the value of "UUID LDAP attribute" is the same of the "Username LDAP attribute"
by Marcelo Arthur Sampaio
Hi,
I get this error when the value of "UUID LDAP attribute" is the same of the "Username LDAP attribute": Ex. "uid"
Caused by: java.lang.NullPointerException
at org.keycloak.models.cache.DefaultCacheUserProvider.getUserByUsername(DefaultCacheUserProvider.java:149) [keycloak-invalidation-cache-model-1.3.1.Final.jar:1.3.1.Final]
at org.keycloak.federation.ldap.LDAPFederationProvider.importLDAPUsers(LDAPFederationProvider.java:391)
The method org.keycloak.federation.ldap.LDAPUtils.getUsername(LDAPObject, LDAPConfig)
dont return the username, because the attribute is not in the map.
This occours because the uid is not added into the map of attributes.
I looked at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.populateAttributedType(SearchResult, Collection<String>) line 402:
if (ldapAttributeName.equalsIgnoreCase(getConfig().getUuidLDAPAttributeName())) {
Object uuidValue = ldapAttribute.get();
ldapObject.setUuid(this.operationManager.decodeEntryUUID(uuidValue));
} else {
Set<String> attrValues = new TreeSet<>();
NamingEnumeration<?> enumm = ldapAttribute.getAll();
while (enumm.hasMoreElements()) {
String attrVal = enumm.next().toString();
attrValues.add(attrVal);
} ...
-
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
8 years, 9 months
Heads up! Unify line endings
by Stian Thorgersen
I'm applying the changes Lukas proposed with regards to line endings tomorrow.
This shouldn't have any impacts on merging changes, but just in case LET ME KNOW ASAP if you have a large amount of uncommitted changes and we'll hold off just in case.
8 years, 9 months
Git History w/merges of upstream/master
by Scott Rossillo
Not the biggest deal, but always see commits like:
"Merge remote-tracking branch 'upstream/master’ commits"
If you `git pull —rebase` you can avoid these and the project history will be a lot cleaner.
~ Scott
8 years, 9 months
That thing for too many logins
by Stan Silvert
Customer: "Does Keycloak block logins after too many failed attempts?".
Me: "Of course, that's really basic stuff."
Customer: "I've looked all over the UI and I can't find it."
Me: "I know it's there, but we did change the UI recently. Don't
remember what it's called."
I click around awhile.
Me: "Oh, here it is. Failure Factor. It's under Security Defenses ->
Brute Force Detection."
Customer: "No wonder I couldn't find it."
Me: "Yea, it needs to be called something else."
What should Failure Factor be called? Maybe "Max Login Failures"?
8 years, 9 months
How to login via Kerberos and Windows AD
by Matthew Casperson
I have done the following steps in an attempt to configure Windows 2008 AD
to work with KeyCloak:
1. Created a windows user called "Keycloak"
2. Run "setspn -s HTTP/virtual.local:8080 Keycloak"to assign the SPN to
the user
3. Run "ktpass -out keycloak.keytab -princ
HTTP/virtual.local:8080@VIRTUAL.LOCAL -mapUser Keycloak -mapOp set -pass
password -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL" to get a keytab file.
4. Set "Kerberos Realm" to "VIRTUAL.LOCAL", "Server principal" to
"HTTP/virtual.local:8080@VIRTUAL.LOCAL" and set the location of the
keytab file in the "Keycloak LDAP User Federation Provider" screen.
5. Saved the following in C:\Windows\krb5.ini:
[domain_realm]
.virtual.local = VIRTUAL.LOCAL
virtual.local = VIRTUAL.LOCAL
When I attempt to log in though, I get the following error:
02:21:58,009 INFO [stdout] (default task-4) principal is
HTTP/virtual.local:8080@VIRTUAL.LOCAL
02:21:58,009 INFO [stdout] (default task-4) Will use keytab
02:21:58,010 INFO [stdout] (default task-4) Commit Succeeded
02:21:58,010 INFO [stdout] (default task-4)
02:21:58,011 WARN
[org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator] (default
task-4) SPNEGO login failed: jav
a.security.PrivilegedActionException: GSSException: Defective token
detected (Mechanism level: GSSHeader did not find the right tag)
at java.security.AccessController.doPrivileged(Native Method)
[rt.jar:1.7.0_79]
at javax.security.auth.Subject.doAs(Subject.java:415)
[rt.jar:1.7.0_79]
at
org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.authenticate(SPNEGOAuthenticator.java:46)
I can't seem to find any reliable information on getting Keycloak
configured with AD, nor on the error "GSSHeader did not find the right tag"
(which seems to indicate everything from invalid config in the windows user
account options to browsers requesting NTLM logins).
Can anyone point me in the right direction with configuring windows and
Keycloak for Kerberos based logins?
--
*Matthew Casperson*
*Senior Front End Developer*
Technology, Space & Distribution
Auto & General Holdings Pty Ltd
P: 07) 3377 8751 (Direct: 3377 8751)
F: 07) 3377 8833
--
This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee.
The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright.
It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised.
If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free.
8 years, 9 months
Extend informations shown on Server Info page
by Vlastimil Elias
Hi,
we just discussed this topic with Stian on
https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure if it
is worth to do or not so we should ask other KC devs for their opinion.
Server Info page contains, beside Providers info, only keycloak version
and server time. It should be good for real management/operations (based
on my few year's experience with jboss.org JIRA, SSO and other system's
operation) to extend it with other informations like:
* server uptime
* version, vendor and variant of jre used to run it
* basic info about OS (type, version)
* info about OS user KC runs under
* info about locale nad timezone used for JVM
* JVM memory statistics (total and free heap mem, perm gen mem)
* basic info about DB in case of JPA (JDBC url, JDBC driver type and
version, DB type and version) or info about used mongo (version etc)
This page should contain this info for all cluster nodes in clustered
environment.
Stian objected that this info is available form EAP/WF console, but I
think it is a bit problematic for common KC admin to access it there as
it is not integrated with KC console.
WDYT?
Thanks in advance
Vl.
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
8 years, 9 months
