Incorrect parsing of GUID from eDirectory
by Sven-Torben Janus
Hey all!
one of my customers wants to implement user federation with eDirectory as LDAP server in place. Everything works fine as long as "Import users" is deactivated.
When activating the import, users can no longer be imported. The import fails with the exception shown in https://issues.jboss.org/browse/KEYCLOAK-10942 when "UUID LDAP attribute" is set to "guid".
The exception seems to come from incorrect parsing of the guid attribute in LDAP. The guid attribute in eDirectory is binary, but is not parsed as such.
I have prepared a PR https://github.com/keycloak/keycloak/pull/6251 to fix this.
However, I am unsure about the current state of support for eDirectory. I have seen these PRs and tickets which indicate eDirectory is supported:
* https://github.com/keycloak/keycloak/pull/1154
* https://lists.jboss.org/pipermail/keycloak-user/2015-April/002023.html
I can also choose "Novell eDirectory" from the Vendor list, so I assume it is supported.
In contrast I see tickets like this one, where it states that it isn't supported.
* https://issues.jboss.org/browse/KEYCLOAK-3099 (btw: that seems to be the same issue as described in KEYCLOAK-10942)
And there has been a discussion around a similar (the same?) issue, years ago: https://lists.jboss.org/pipermail/keycloak-user/2016-November/008428.html
Can anyone please clarify on the current state of eDirectory support and whether my fix has a chance be released?
Regards
Sven-Torben
--
Sven-Torben Janus
Senior Software Architect (Dipl.-Inf.), iSAQB® CPSA-A
Conciso GmbH | Westfalendamm 251 | 44141 Dortmund
E sven-torben.janus(a)conciso.de
W https://conciso.de
Rechtlicher Hinweis/Legal notice:
Sitz der Gesellschaft/Registered Office: Dortmund
Amtsgericht/Trade Register: Dortmund, HRB 28364
Geschäftsführer/Managing Directors: Sebastian Neus, Dr. Georg Pietrek, Jens Trompeter
6 years
Add SAML Extensions (and AuthContext) as another client note to the AuthenticationSessionModel in SamlService
by Roland
Hello,
when a SAML Request is received in Keycloak, the method loginRequest in
abstract class BindingProtocol in class
org.keycloak.protocol.samlSamlService puts the information from the request
into the AuthenticationSessionModel in this section of code:
authSession.setProtocol(SamlProtocol.LOGIN_PROTOCOL);
authSession.setRedirectUri(redirect);
authSession.setAction(
AuthenticationSessionModel.Action.AUTHENTICATE.name());
authSession.setClientNote(SamlProtocol.SAML_BINDING,
bindingType);
authSession.setClientNote(GeneralConstants.RELAY_STATE,
relayState);
authSession.setClientNote(SamlProtocol.SAML_REQUEST_ID,
requestAbstractType.getID());
What we are missing here is the SAML Extensions, which happen to be in the
SAML Request which we receive, and which we want to pass on to a brokered
external Identity Provider.
For example something like this:
ExtensionsType et = requestAbstractType.getExtensions();
List<Object> list = et.getAny();
<create some kind of String representation>
authSession.setAuthNote("SAML_EXTENSION", <the String
representation>);
In the same way we would also like access to the AuthContext through the
authSession.
I would offer to contribute this if the community approves the idea.
Thanks and Regards,
Roland
6 years
WebAuthn testing
by Marek Posolda
We have community PR for adding initial webauthn support [1]. The PR is
great work for the start IMO (anyone welcome to review PR :)
But among other things, it touches one of the challenges for webauthn
support, which is automated testing. So far, the PR introduces testing
webauthn with the Chrome WebDriver and the Chrome testing API [2] . The
Chrome Testing API allows chrome browser to "simulate" the webauthn
authenticator without having the real webauthn authenticator device
available.
IMO it is fine to use the Chrome Testing API for the parts, which are
more focus on the Keycloak integration itself rather than on the details
of WebAuthn configurations. From one point of view, it may be sufficient
to test just with Chrome Testing API as Keycloak is just WebAuthn
Relying party and it doesn't need to care which underlying WebAuthn
authenticator was used - that's more the responsibilty of the platform
and web browser, which sends HTTP requests to Keycloak. However I afraid
that there may be some cases where this is not sufficient and we may
need some more proper interoperability testing. Especially for testing
the details of webauthn specification. For example if Keycloak sends the
WebAuthn registration request with "userVerification: required", we may
need to ensure that authentication will fail if userVerification flag is
not provided by the authenticator etc.
So what are possible options?
(a) Use just testing with chrome testing API and rely on the underlying
webauthn library (webauthn4j) to hide the webauthn specification
interoperability testing. This may be the easy option, but not sure
whether sufficient?
(b) Look at WebDriver Authenticator Extension and check if/when it is
possible to use it. Details here [2] (also see the open PR linked from
there). I am not sure when this will be available for us to be able to
consume it, so not sure if this is an option...
(c) Look at FIDO Alliance certification conformance [3] and investigate
if it provides some automated tests, which can be somehow
used/forked/duplicated to our testsuite
(d) Check how webauthn4j library (and eventually some other libraries)
are doing automated tests and inspire from them if possible.
(e) Test manually with some defined set of webauthn authenticators on
some defined set of platforms/browsers. Then investigate which HTTP
requests were sent to Keycloak from the browser for various
configuration options and use those manual tests to create some
"client", which will just use Apache HTTP Client under the covers to
directly send HTTP requests to Keycloak. In other words, just simulate
the browser+OS+Authenticator. This is not ideal, however possibly useful
as a fallback option?
(f) any better option?
[1] https://github.com/keycloak/keycloak/pull/6248/files
[2]
https://chromium.googlesource.com/chromium/src/+/a82bdb76536b5fce18573422...
[3] https://github.com/w3c/webauthn/issues/1236
[4]
https://fidoalliance.org/certification/functional-certification/conformance/
Marek
6 years
Putting a value into a custom Protocol mapper
by Chris Smith
I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim
I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket
public Subject authenticateSubject(String username, String password) throws LoginException {
String principal = getKerberosPrincipal(username);
logger.debug("Validating password of principal: " + principal);
loginContext = new LoginContext("does-not-matter", null,
createJaasCallbackHandler(principal, password),
createJaasConfiguration());
loginContext.login();
serializedKerberosTicket = serializeTicket();
logger.debug("Principal " + principal + " authenticated succesfully");
return loginContext.getSubject();
}
private String serializeTicket() {
KerberosTicket kerberosTicket = loginContext.getSubject()
.getPrivateCredentials(KerberosTicket.class)
.stream().findFirst().get();
try (ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos)){
oos.writeObject(kerberosTicket);
return Base64.getEncoder().encodeToString(bos.toByteArray());
} catch (IOException e) {
logger.error("Kerberos ticket serialization failed", e);
return null;
}
}
I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator.
Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token?
I have looked and googled with no luck.
6 years
Re: [keycloak-dev] passing SAML extensions and context to custom authenticators
by Caranzo Gideon
Hi Hynek,
Thank you for your response. Yes, I agree with you. It would be good to have this mechanism in those areas as well.
I already have a PR ready for just the SAML login portion. Is it fine with you if I submit this first so that we can use it as early as possible? We can create a separate ticket to implement similar mechanism for other SAML messages and broker endpoint which can be done in near future.
Thanks,
Gideon
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Hynek Mlnarik
Sent: Thursday, January 24, 2019 1:58 AM
To: Gideon Caranzo <gideonray(a)gmail.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] passing SAML extensions and context to custom authenticators
Hi Gideon,
thanks for the idea. Something like that would be a useful enhancement. The implementation would need to cover also the broker endpoint, other SAML message types (extensions are part of message types other than AuthnRequest as well), and count on several implementations of the hypothetical SamlAuthenticationPreprocessor. Could you please file an "Enhancement" JIRA?
--Hynek
On Wed, Jan 16, 2019 at 5:49 PM Gideon Caranzo <gideonray(a)gmail.com> wrote:
> Hi All,
>
> I'd like to propose a feature that allows custom authenticators to
> handle SAML extensions, authentication context and other request attributes.
>
> Right now in OIDC, all request claims are passed to custom
> authenticators which allows for customized behavior depending on the claims.
> However, this is not the case for SAML. Only attributes that are
> explicitly set (e.g. NameID) in the auth session are passed to custom authenticators.
>
> Information like SAML extension and authentication context are not
> available which limits the ability to define custom behaviors. In the
> past, we ran into similar limitation and we had to update keycloak
> core to add support for NameID attribute.
>
> To solve this, we can have an optional hook that pre-process SAML
> login request right before authentication. The hook can then extract
> the needed attributes and set it accordingly for custom authenticators to process.
>
> The pre-processing will be done in
> *SamlService.BindingProtocol.loginRequest()*:
>
> *public* *class* SamlService *extends* AuthorizationEndpointBase {
>
> *. . .*
>
> *public* *abstract* *class* BindingProtocol {
>
> . . .
>
> *protected* Response loginRequest(String relayState,
> AuthnRequestType requestAbstractType, ClientModel client) {
>
> . . .
>
> SamlAuthenticationPreprocessor preProcessor = session
> .getProvider(SamlAuthenticationPreprocessor.*class*);
>
> *if* (preProcessor != *null*) {
>
> preProcessor.process(requestAbstractType, authSession);
>
> }
>
>
>
> *return* newBrowserAuthentication(authSession,
> requestAbstractType.isIsPassive(), redirectToAuthentication);
>
> }
>
>
> Let me know what you think. Thanks.
>
> Best regards,
> Gideon
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> ts.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cgi
> deon.caranzo%40gemalto.com%7C6f947d88676b4f788b2108d681d1d529%7C37d0a9
> db7c464096bfe31add5b495d6d%7C0%7C0%7C636839135555784466&sdata=Yhpx
> 28KFJWJGa1kv1ROWWqJd3nt60YvAb0YmeKUU5Mg%3D&reserved=0
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists....
________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
6 years
Password Updates and Authenticators in the new Account Console
by Václav Muzikář
Hello,
I wanted to discuss the new Account Console which is in development and how
it handles password updates and authenticators configuration (e.g. TOTP).
Currently, when a user wants to update their password [see attached A.png]
or configure authenticator [B.png] they cannot do it directly from the
Account Console. They need to be redirected back to Keycloak and perform it
there in form of Required Action [C.png, D.png] – which is technically the
login screen (it uses the same template). This also means there will be no
REST endpoints for changing passwords or managing authenticators.
IMHO this is not the best approach either for users or developers (who'll
be using Keycloak with their app). Let me explain why.
- It's not really user friendly. Redirecting from one application to
seemingly completely different application is never good and can be
confusing. I can imagine some less tech savvy users could even feel "in
danger" – one second you're securely managing your account and then you are
asked to change your password in some other application (that suspiciously
uses the same design as login screen).
- This approach doesn't feel seamless. You can change e.g. your name,
email, etc. directly from the Account Console. But not password and
authenticators...
- It's not an industry standard. I haven't ever encountered anywhere
that I'd have to be redirected from some profile managing app to completely
different app just to change password. Again – it's confusing for the users
to do something differently than they're used to and what they expect.
- Network traffic overhead. People accessing the Account Console will
often use some limited and slow internet connection. Needless redirecting
back and forth and loading the application again takes data and time.
- Missing REST endpoints limit developers. With a proper REST API devs
could e.g. fully integrate the Account Console functionality into their own
app (and effectively replacing the Console by their app). This also means
no CLI apps support. And I don't think REST API is less secure than
Required Actions – either way you're sending an HTTP request and how it's
secure depends on the same factors for both.
- We're stripping out core Account Console functionality. It was always
a central place to manage your account. Now it can do what? Change your
email and manage apps access? (We could as well replace it with bunch of
links to Required Actions. :P There're are already Required Actions for
changing email and name.)
I can see however one advantage of this approach. There's only one place
where users can change their passwords and authenticators – no need to
implement it second time when it's already implemented as Required Actions.
But this is actually not entirely true as e.g. password changing process
(incl. password policies etc.) is implemented in Admin Console too so there
needs to be some shared logic.
In general this approach practically benefits "only" the implementation
complexity – it's easier to do it this way and therefore less error prone.
WDYT? Should we keep the current approach?
Thank you!
V.
--
Václav Muzikář
Senior Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.
6 years
Connecting to an external database for a ProtocolMapper
by Thomas
I need help finding the correct direction of creating a ProtocolMapper that
reads from an external database.
We currently have a Spring microservice application that uses Spring OAuth2
secured services with a Spring OAuth2 server that adds claims to the access
token to implement extra claims for security. The application also reads
the extra claims from the user service database. This database doesn't
store user authentication credentials. User authentication data is in an
enterprise LDAP/AD that is read only. I will never be able to change the
read only LDAP. We would like to get rid of the Spring OAuth2 server.
So far, I've been able to import users into Keycloak from the LDAP and get
every microservice to respond correctly to a request from a valid token
from Keycloak once a login has happened. I've also been able to get a
ProtocolMapper running that adds hard coded claims to the user's access
token.
I would like to use a few custom Spring libraries that we have created for
other services to read data from the User Service Database. The libraries
all ready have implemented a ReadOnly Repository that has custom SQL
types. Particularly, arrays of strings and ints. As well as the Domain
model.
Should I create an EAR that includes the ProtocolMapper as a jar module?
What is the correct way to structure the EAR? Will using my other
libraries that use Spring work?
Thanks,
Thomas
6 years
External (SAML) Token to Internal Token Exchange
by Edwin Steiner
Hi all
First, thanks to all Keycloak committers and contributors. We like Keycloak very much and have used it in many projects.
The documentation says that the "Token Exchange" [1] feature is in Technology Preview only and the "External Token to Internal Token Exchange" [2] feature for SAML identity providers is not supported but may be added.
In a customer project we have exactly the requirement for exchange a SAML v2 Assertion with a JWT. Because of that we are investigating in implementing this feature either as a project specific solution or as a contribution.
As there is no SPI for this requirement, I guess a fork is necessary for changing the method org.keycloak.protocol.oidc.endpoints.TokenEndpoint#tokenExchange, so that not only subject tokens of type "urn:ietf:params:oauth:token-type:jwt" are accepted.
Any hints or tips on this topic are very welcomed.
Best regards
Edwin
[1] file:///Users/esteiner/Documents/Github/Keycloak/keycloak-documentation/target/securing_apps/index.html#_token-exchange
[2] file:///Users/esteiner/Documents/Github/Keycloak/keycloak-documentation/target/securing_apps/index.html#external-token-to-internal-token-exchange
--
Edwin Steiner
Inventage AG | CH-8005 Zürich | www.inventage.com
6 years, 1 month
