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.
4 years
Re: [keycloak-dev] translate keycloak
by Eugen Stan
Bump.
Hello again. We managed to translate some languages already and we would
like to contribute the translations upstream and hopefully improve the
translation process.
We have some feedback from our process. We use this process internally
and the idea is to have it working for keycloak open source
Proposal for Keycloak
- We propose to move the community translations in a separate git
project - just with the translations
- That repository is going to be used by Weblate as a source of
translations ( use Free Hosted Weblate - https://hosted.weblate.org/ )
- The translations project can be added as a git sub module to the
keycloak project
- during build the translations can be copied to the final artifact
We do this allready and we can help with the code migrations. Having
this setup will improve the contributions to translations and also the
ability to change the translations easily.
WDYT?
Regards,
Eugen
La 01.12.2018 19:22, Eugen Stan a scris:
> Hello,
>
> Where can we find the translation files for Keycloak and what is the
> process for upstreaming them?
>
> We are planning to deploy Keycloak for authentication for our services.
> We have users all accross the globe and we have translators that we can
> ask to translate.
>
> I'm planning to push the translations upstream once they are done (need
> to get approbal on this).
>
>
> Regards,
>
> Eugen
>
>
>
4 years, 5 months
Application Initiated Actions
by Stian Thorgersen
Keycloak currently has required actions that are used to prompt the user to
perform an action associated with their account after authenticating, but
prior to being redirected to the application.
Examples include: configure OTP, update profile, validate email, etc.
One issue here is these actions have to be manually registered with the
users account, but can not be initiated by applications themselves. As an
example it may not be required by all users to verify their email, but only
when they use specific applications.
Keycloak also needs to initiate actions from the account management
console. Examples: updating email address should require verifying the
email, configuring OTP, etc.
With that in mind we are proposing to introduce Application Initiated
Actions. An Application Initiated Action behind the scenes is just a
Required Action, but it is initiated by an application and depending on the
action may be optional for the user to complete (where the user can select
cancel which would return the user back to the application).
No Application Initiated Actions should perform any updates to the users
account without prompting the user first. For example an application
initiated action that is used to link an existing account to a social
provider should ask the user first if they want to link to the provider.
To make it easy for applications to integrate these I would like to
leverage the standard OAuth flows that applications use to authenticate
users. So to initiate verify-email action the application would redirect to
the authentication endpoint and add kc_action=<action alias> query
parameter.
One open question I have right now is. Assuming all Application Initiated
Actions always prompt the user first do we need to add some mechanism in
place to restrict what clients/applications are permitted to initiate an
action? Requiring that would make it harder to use for applications.
One thing I would also like to add is the ability for an Application
Initiated Action to require the user to re-authenticate prior to performing
the action. For example update password should require the user to enter
the current password, while verify email should not (as it simply sends an
email with a link to continue).
4 years, 6 months
Allow AdminEvents for custom resource types
by Lösch, Sebastian
Hello devs,
we implemented a custom resource type as an extension to keycloak.
For traceability reasons we would like to track actions for this custom resource type via AdminEvents.
Unfortunately the resource type is represented by the enum ResourceType. Therefore no AdminEvents for custom non standard resource types can be created.
It would be nice if it is possible to specify the resource type as string value also.
This is only a small change, because the resource type is only provided via enum but handled as string value internally.
I provided a pull request for that enhancement: https://github.com/keycloak/keycloak/pull/5882
May anybody have a look on that review?
Best regards,
Sebastian
4 years, 6 months
Improving support for LDAP backed Keycloak
by Dan Hardiker
Hi All,
Sorry for such a long first post. Here we go!
TL;DR:
I want to look at https://issues.jboss.org/browse/KEYCLOAK-5571 as it is impacting us. I’m happy to contribute code or write a blog on what configuration settings are needed to achieve this. While the SAGA has more context, here’s a few of my currently burning questions:
1. What implements the org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) and UserRepresentation ...toRepresentation() interface method? (from the integration/admin-client directory - I can’t find the business logic)
2. What would be the right approach to wire up the admin ui User Enabled toggle to a LDAP boolean field, and where in the codebase would that go? (if you can cite examples of similar that would be great)
3. What is the best way to go about setting up an IDE for development? Just importing the root POM into IDEA doesn’t seem to cut it.
4. If I provide a patch for this, is this something that might be considered for pulling into master?
I am interested in all of the features within KEYCLOAK-5571, as a few other requirements, but I’m happy to start here and treat the others as atomic suggested changes. They may include:
* Supporting incremented default values for new users (the uidNumber must be unique and it should be 1 greater than the highest uidNumber that the system can see … i.e. the next available UID).
* Supporting out-of-band password recovery (where by a code is sent via a trusted path [text message, telephone call, in person conversation with the user] which can be used to reset their password - ideally in combination with another stored value, such as their employee id / tax id / post code / something else which is relatively static but relatively unknown) - this could be developed outside of Keycloak of course, but would ideally be within the same system.
If addressing KEYCLOAK-5571 goes well, I would be interested in continuing to contribute down these paths.
Thanks for your time, I would love to get involved … I just need a bit of help.
THE SAGA:
Apologies if this message should be in keycloak-users, and if any of it seems incoherent. I’ve been fighting in circles all weekend and I have to admit that I’m not entirely sure I’m approaching the problem correctly. Please bear with me as I’m not entirely sure how to articulate things at this point, but I know I need help!
Problem statement: we are currently using OpenLDAP to manage access to our systems. However, the administration interface is crude and it lacks SAML/OIDC support for integrating systems like Google Suite, AWS Console, Office 365 and others. It also lacks a self service console where users can mange their own accounts. Keycloak at first glance looks ideal - especially as it allows us to continue using OpenLDAP as the primary source of truth, with Keycloak used to enhance the user experience giving self service and integration with SAML/OIDC clients.
As per the docs, some mapping is required to have OpenLDAP support the storage of Keycloak data within the OpenLDAP schemas. Unfortunately, I’ve not bee able to find documentation for what those fields names in Keycloak can be and how I should alter my OpenLDAP schema to support them. I found KEYCLOAK-5571 which appears to cover at least some of the issues I’m having. Amongst other things, I’m a Java developer, so I’m comfortable with working in code and submitting patches. Assuming that the answer isn’t configuration, is this something that would be valuable to contribute? If so, is there any advice that this list can offer on where to start?
What follows is my journey as an outsider into trying to figure out things myself. This may or may not be of interest - but given this list gets indexed by Google, it might help someone in future. Seeing that issue (KEYCLOAK-5571) I figured the best place to start would be the admin ui where you enable/disable users. I thought that I would start at the browser and try to figure out what the enabled/disable user toggle did when saved, trace that into the server side endpoint that picked up that representation and hopefully find out where & why it didn’t make it through to LDAP.
I noticed that there was a PUT to http://localhost/auth/admin/realms/master/users/f:$UUID:$USERNAME and as part of the JSON payload was “enabled: false”. At this point I started grepping around in the Keycloak code. I figured that org.keycloak.admin.client.resource.UserResource.update(UserRepresentation) Interface was what was being called, but unfortunately when I opened up the root POM then IDEA only saw the files as plain text and none of the Intelisense worked, I could grep around the code though. When I opened up the integration/admin-client/pom.xml it recognise the Java files, however I wasn’t able to find what was implementing this. If found "public static UserRepresentation toRepresentation(KeycloakSession session, RealmModel realm, UserModel user)” in server-spi-private org.keycloak.models.util.ModelToRepresentation, but couldn’t find the glue which connects them together. I’m guessing there might be some WildFly or other magic going on which I’m not aware of?
Seeing the “enabled: false” lead me to think that I might be able to create a user-attribute-ldap-mapper from the user model attribute “enabled” to an “enabled” LDAP attribute I added to our schema to test. The LDAP attribute has SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 (a binary attribute) and I’ve checked I can set that to TRUE / FALSE appropriately. I set it to be mandatory in LDAP and set it to be a Binary Attribute - however when I save it says "Error! With Binary attribute enabled, the 'Always read value from LDAP' must be enabled too” - however there is no “Always read value from LDAP” option! However, after enabling Import Users in the LDAP user federation settings, “Always read value from LDAP” becomes available. It’s not clear if Binary Attributes are supported only in this configuration, but ideally I would like to not Import Users as I prefer LDAP to be the authoritative source. After this I can disabled Import Users and the configuration still seemingly remains valid without any errors in the logs. That said, it’s not erroring about not properly persisting the enabled state to LDAP...
If I go across to the user in the admin ui, even though enabled is set to FALSE in LDAP, the toggle is showing as enabled in the UI. The JSON it gets for the UserRepresentation on the client side is “enabled”:true which explains the state of the toggle. If I stick Wireshark locally, setup a Docker with OpenLDAP and configure it appropriately, sniffing traffic I can see that the enabled attribute for my user comes back as FALSE. So there is something going wrong when trying to build that UserRepresentation. I suspect at the root of the KEYCLOAK-5571 issue. If I change the toggle to false in the UI and save, then reload the page, the toggle is back to true - when it persists to the LDAP server, it’s sending enabled: FALSE - this doesn’t make sense, but it might be just repeating back to LDAP what it read in without changing that field. If I change the name as well, it does send those fields updated, but enabled remains FALSE in the LDAP server.
Given that I didnt get very far with the UserRepresentation angle, I thought about going down the FederatedStorage - something must map the model into LDAP, as changes to the first name / last name, and the other attributes seem to be persisted and loaded in LDAP just fine. In my grepping around in server-spi I found a org.keycloak.models.UserModel Interface, which had a org.keycloak.storage.adapter.AbstractUserAdapterFederatedStorage implementation with a ENABLED_ATTRIBUTE = “ENABLED” field and isEnabled / setEnabled methods which getFirstAttribute(ENABLED_ATTRIBUTE) / setSingleAttribute(ENABLED_ATTRIBUTE, Boolean.toString(enabled). The class comment has:
* Assumes everything is managed by federated storage except for username. getId() returns a default value
* of "f:" + providerId + ":" + getUsername(). UserModel properties like enabled, firstName, lastName, email, etc. are all
* stored as attributes in federated storage.
I’m not sure how the case difference between “enabled” in the UserModel properties and “ENABLED” as listed in the class field is connected - but there must be a mapping somewhere, as “firstName” is similarly “FIRST_NAME” and that maps just fine. I found model/jpa contained org.keycloak.models.jpa.entities/UserEntity which had @Column(name = "ENABLED”) protected boolean enabled, perhaps this is the link and even with Import Users disabled it always goes through the database?
I’ve yet to find the trigger which calls the mapper to run which persists into the database. Part of the problem is that I’m acutely aware my IDE is not setup to effectively jump around the code base, or to effectively attach my IDE as a debugger so I can add breakpoints and step through the code to figure out what happens where. I’ve just turned on trace logging - but this is giving me a wall of text which may take sometime to process. I’ve also yet to comb through the H2 DB to see if there’s cause there.
Any assistance on this would be most welcome.
ON ANOTHER NOTE:
I checked out the code and ran the build as documented against Java 8 on my mac, but unfortunately it failed. I ignored it and progressed, but here’s some excerpts from the output:
[INFO] Keycloak Integration TestSuite - deprecated ........ FAILURE [07:04 min]
[ERROR] Errors:
[ERROR] OIDCKeyCloakServerBrokerBasicTest.testLogoutWorksWithTokenTimeout:131 » Processing
[ERROR] OIDCKeycloakServerBrokerWithConsentTest.before:84 » Processing java.lang.NoSuc...
[ERROR] BrokenUserStorageTest.testBootWithBadProviderId:118 » Processing java.lang.NoS...
[ERROR] JaxrsBasicAuthTest.testBasic:120 » NoSuchMethod org.apache.commons.io.output.D...
[ERROR] JaxrsFilterTest.testBasic:129 » NoSuchMethod org.apache.commons.io.output.Defe...
[ERROR] Tests run: 238, Failures: 0, Errors: 5, Skipped: 32
I guess this shouldn’t happen on a fresh check out & a following of the instruction.
If you made it this far - bravo!
Thanks again,
—
Dan Hardiker | Adaptavist
4 years, 6 months
Removing JaxrsBearerTokenFilter
by Marek Posolda
I wonder if we can remove JaxrsBearerTokenFilter?
Jut to add some context, the JaxrsBearerTokenFilter is the "adapter",
which we have in the codebase and which allows to "secure" the JaxRS
Application by adding the JaxrsFilter, which implements our OIDC
adapter. Bill added this thing in the early days of Keycloak. I enhanced
it a bit few years ago as someone wanted to secure the JaxRS application
on Fuse. But this was before we had the proper Fuse adapter.
This thing was never documented and we never had any
examples/quickstarts for it. We have just few automated tests (in the
old testsuite). IMO it is very obsolete now as you can probably always
secure your application through some other oficially supported way (HTTP
Servlet filter or any of our other built-in adapters).
Does anyone have any reason why we shouldn't remove this?
If not, I wonder if we can remove it directly without "deprecation
period"? Considering that this was never documented or announced, it
probably can't be treated as a Keycloak feature, but rather an
"implementation detail" or "prototype" and hence removing it directly
may be fine? In this case, we won't need to migrate the tests from the
old testsuite (which is my main motivation for writing this email :)
Marek
4 years, 6 months
Support for more flexible SAML handling for Attribute, AttributeValue and AttributeStatement elements
by Thomas Darimont
Hello,
In my current project I needed to support extensive customizations of SAML
"Attribute"-elements in Keycloak SAML responses.
Unfortunately keycloaks
"org.keycloak.protocol.saml.mappers.SAMLAttributeStatementMapper" was not
powerful enough to support
all required customizations.
Some features that were missing / problems I faced were:
- Support for custom AttributeValue types, c.f. "xsd:anyURI" to represent
urn:oid values
- Support for complex nested elements (see example below)
- SAMLAttributeStatementMapper's effectivenes is restricted by
org.keycloak.saml.processing.core.saml.v2.writers.BaseWriter.writeAttributeTypeWithoutRootTag
- Lacking support for custom core protocol implementations, like "saml"
- provider-id "saml" should not be used to identify the "protocol"
Here is an example "AttributeStatement" fragment that I needed to support.
...
<AttributeStatement>
<Attribute Name="Role"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<AttributeValue xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:string">dummy</AttributeValue>
</Attribute>
<Attribute FriendlyName="XSPA Organization ID"
Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<AttributeValue xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xsd:anyURI">urn:oid:1.2.3.4.5.6.7.8.9.10.11.12</AttributeValue>
</Attribute>
<Attribute FriendlyName="Acme Role"
Name="urn:oasis:names:tc:xacml:2.0:subject:role"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<AttributeValue xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:anyType">
<Role code="PRA" codeSystem="1.2.3.4.5.6.7.8.9.10.11.12"
codeSystemName="IHEXDShealthcareFacilityTypeCode"
displayName="Doctor's office" xmlns="urn:hl7-org:v3"/>
</AttributeValue>
</Attribute>
</AttributeStatement>
...
a full example for a complete SAML response can be found here for
reference:
https://gist.github.com/thomasdarimont/02a7861562d0684861b213a1d16b7047
I eventually managed to customize the SAML responses as needed, but my
approach is probably not 100% future proof...
If anyone here knows a better way to do this, I'm all ears :)
Nevertheless, it would be great if Keycloaks support for custom SAML
attributes would be more flexible in the future.
Anyways, here is what I had to do in order to get the required SAML
customizations working:
- Create a "org.keycloak.protocol.LoginProtocolFactory" extension and
reference "CustomSamlProtocolFactory"
- Create class CustomSamlProtocolFactory extends SamlProtocolFactory
- Create class CustomSamlProtocol extends SamlProtocol and return a new
CustomSamlProtocol instance in CustomSamlProtocolFactory#create(..) (see
below)
- override
org.keycloak.protocol.saml.SamlProtocol#buildAuthenticatedResponse
-> protected Response
buildAuthenticatedResponse(AuthenticatedClientSessionModel clientSession,
String redirectUri, Document samlDocument, JaxrsSAML2BindingBuilder
bindingBuilder)
-> samlDocument contains the SAML document populated by Keycloak BEFORE
it is signed and encrypted
-> clientSession gives you access to the current user etc.
-> add custom SAML processing as needed
-> call return super.buildAuthenticatedResponse(clientSession,
redirectUri, samlDocument, bindingBuilder); at the end, this potentially
signs and encrypts the SAML document
- Make keycloak aware of that extension... (tricky, read on)
Note that the "CustomSamlProtocolFactory" uses the same provider ID "saml"
as the "SamlProtocolFactory" does -> this leads to a name clash...
unfortunantely Keycloak currently doesn't support to have custom
implementations for core protocols.
Here comes the hack:
In order to let Keycloak pickup my "CustomSamlProtocolFactory"
implementation before it's own "SamlProtocolFactory", I needed to copy the
provider jar to
`$KEYCLOAK_HOME/modules/system/layers/keycloak/org/keycloak/keycloak-services/main`
and change the keycloak-services module.xml to:
<resources>
<resource-root
path="simple-custom-saml-protocol-1.0.0.0-SNAPSHOT.jar"/> <!-- added this
-->
<resource-root path="keycloak-services-4.8.3.Final.jar"/>
</resources>
With that change Keycloak picked up my custom "CustomSamlProtocolFactory"
first and I could adjust the SAML document as required.
Btw. you might be wondering why I didn't just create a new
"CustomSamlProtocolFactory" with a dedicated provider-id like "saml-custom"
and use that for clients. We'll that was my first try, but unfortunately
this is currently not possible, since the Admin-Console
UI for the SAML configuration seems to be hard-coded against the
provider-id "saml"... so I'm stuck with the current "solution".
It would be great if the "LoginProtocolFactory" SPI would support custom
protocol implementations, while reusing protocol configuration options and
the admin-console ui.
Cheers,
Thomas
Ps.:
FYI this is what a SAMLAttributeStatementMapper allows you to do currently
(Keycloak 4.8.3.Final):
// SimpleSamlMapper
...
@Override
public void transformAttributeStatement(AttributeStatementType
attributeStatement, ProtocolMapperModel mappingModel, KeycloakSession
session, UserSessionModel userSession, AuthenticatedClientSessionModel
clientSession) {
// transform attributeStatement here
LOGGER.infof("transformAttributeStatement");
AttributeType bubu = new AttributeType("bubu");
bubu.setFriendlyName("FriendlyBubu");
bubu.setNameFormat("urn:oasis:names:tc:SAML:2.0:attrname-format:basic");
bubu.setName("Bubu");
bubu.addAttributeValue("Object allowed but only Strings or
NameIDType supported here...");
// see: bottom of
org.keycloak.saml.processing.core.saml.v2.writers.BaseWriter.writeAttributeTypeWithoutRootTag
// would be great to have support for AttributeValue type
customizations, even if value is String.
// would be great to have support for complex XML element as values
attributeStatement.addAttribute(new
AttributeStatementType.ASTChoiceType(bubu));
}
...
// CustomSamlProtocolFactory
import org.keycloak.models.KeycloakSession;
import org.keycloak.protocol.LoginProtocol;
import org.keycloak.protocol.saml.SamlProtocolFactory;
public class CustomSamlProtocolFactory extends SamlProtocolFactory {
public LoginProtocol create(KeycloakSession session) {
return (new CustomSamlProtocol()).setSession(session);
}
}
// CustomSamlProtocol
import org.keycloak.models.AuthenticatedClientSessionModel;
import org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder;
import org.keycloak.protocol.saml.SamlProtocol;
import org.keycloak.saml.common.constants.JBossSAMLURIConstants;
import org.keycloak.saml.common.exceptions.ConfigurationException;
import org.keycloak.saml.common.exceptions.ProcessingException;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import javax.ws.rs.core.Response;
import java.io.IOException;
public class CustomSamlProtocol extends SamlProtocol {
protected Response
buildAuthenticatedResponse(AuthenticatedClientSessionModel clientSession,
String redirectUri, Document samlDocument, JaxrsSAML2BindingBuilder
bindingBuilder) throws ConfigurationException, ProcessingException,
IOException {
// TODO use Keycloak provider information from this.session
Element assertionElement = (Element)
samlDocument.getElementsByTagNameNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"Assertion").item(0);
Element attributeStatementElement = (Element)
assertionElement.getElementsByTagNameNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"AttributeStatement").item(0);
if (attributeStatementElement == null) {
attributeStatementElement =
samlDocument.createElementNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"AttributeStatement");
assertionElement.appendChild(attributeStatementElement);
}
// TODO pull information from user attributes
attributeStatementElement.appendChild(newSamlAttributeElement(samlDocument,
null, "Role", JBossSAMLURIConstants.ATTRIBUTE_FORMAT_BASIC.get(), "dummy",
"xsd:string"));
// see: http://oid-info.com/get/
attributeStatementElement.appendChild(newSamlAttributeElement(samlDocument,
"XSPA Organization ID",
"urn:oasis:names:tc:xspa:1.0:subject:organization-id",
JBossSAMLURIConstants.ATTRIBUTE_FORMAT_URI.get(),
"urn:oid:1.2.3.4.5.6.7.8.9.10.11.12", "xsd:anyURI"));
Element roleElement =
samlDocument.createElementNS("urn:hl7-org:v3", "Role");
roleElement.setAttribute("code", "PRA");
roleElement.setAttribute("codeSystem",
"1.2.3.4.5.6.7.8.9.10.11.12");
roleElement.setAttribute("codeSystemName",
"IHEXDShealthcareFacilityTypeCode");
roleElement.setAttribute("displayName", "Doctor's office");
attributeStatementElement.appendChild(newSamlAttributeElement(samlDocument,
"Acme Role", "urn:oasis:names:tc:xacml:2.0:subject:role",
JBossSAMLURIConstants.ATTRIBUTE_FORMAT_URI.get(), roleElement,
"xsd:anyType"));
return super.buildAuthenticatedResponse(clientSession, redirectUri,
samlDocument, bindingBuilder);
}
private Element newSamlAttributeElement(Document samlDocument, String
friendlyName, String name, String nameFormat, Object value, String type) {
Element targetSamlAttributeElement =
samlDocument.createElementNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"Attribute");
if (friendlyName != null) {
targetSamlAttributeElement.setAttribute("FriendlyName",
friendlyName);
}
targetSamlAttributeElement.setAttribute("Name", name);
if (nameFormat != null) {
targetSamlAttributeElement.setAttribute("NameFormat",
nameFormat);
}
Element samlAttributeValue =
samlDocument.createElementNS(JBossSAMLURIConstants.ASSERTION_NSURI.get(),
"AttributeValue");
samlAttributeValue.setAttribute("xmlns:xsi", "
http://www.w3.org/2001/XMLSchema-instance");
samlAttributeValue.setAttribute("xsi:type", type);
targetSamlAttributeElement.appendChild(samlAttributeValue);
if (value instanceof String) {
samlAttributeValue.setTextContent((String) value);
} else if (value instanceof Element) {
samlAttributeValue.appendChild((Element) value);
} else if (value != null) {
samlAttributeValue.setTextContent(value.toString());
} else {
samlAttributeValue.setTextContent(String.valueOf(value));
}
return targetSamlAttributeElement;
}
}
4 years, 7 months
Designs in the open starting with WebAuthn Two Factor experience
by Stian Thorgersen
Going forward when we are working on new larger features we will be
creating design documents (epic briefs, call it whatever you want) and
sharing them openly with the community.
I have setup a new repository on GitHub where we will create designs as
simple MarkDown files. This will make it easy for everyone to comment as
well as contribute to the designs.
In contrary to everything else using JIRA for issues, we will use GitHub
issues for issues associated with the designs. We also welcome PRs to
contribute to the designs.
First design to be available is for W3C Web Authentication focusing on the
Two Factor experience. The design is available here
https://github.com/keycloak/keycloak-community/blob/master/design/web-aut...
.
4 years, 7 months
dockerimage for jboss/keycloak-examples seems to be broken
by Thomas Darimont
Hello,
just noticed that the jboss/keycloak-examples image doesn't start anymore,
see below:
Cheers,
Thomas
$ docker run -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin
jboss/keycloak-examples
Unable to find image 'jboss/keycloak-examples:latest' locally
latest: Pulling from jboss/keycloak-examples
aeb7866da422: Already exists
157601a0b538: Already exists
642f4164f381: Already exists
ee2abcb9139a: Already exists
10f7cea861e1: Pull complete
276721013b76: Pull complete
1c8d22278e14: Pull complete
f1339a2aa9d9: Pull complete
d6446eeff2ef: Pull complete
Digest:
sha256:e141cdcd0634813b3d1c4ce1b3c6683088c332ffce5bf74a2a01b194db46b449
Status: Downloaded newer image for jboss/keycloak-examples:latest
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/jboss/keycloak-demo/keycloak
JAVA: /usr/lib/jvm/java/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M
-XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true
-Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
11:13:33,660 INFO [org.jboss.modules] (main) JBoss Modules version
1.8.5.Final
11:13:33,841 INFO [org.jboss.msc] (main) JBoss MSC version 1.4.2.Final
11:13:33,849 INFO [org.jboss.threads] (main) JBoss Threads version
2.3.2.Final
11:13:33,932 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049:
WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) starting
11:13:34,457 ERROR [org.jboss.as.controller] (Controller Boot Thread)
OPVDX001: Validation error in standalone.xml
-----------------------------------
|
| 32: <extension module="org.wildfly.extension.security.manager"/>
| 33: <extension module="org.wildfly.extension.undertow"/>
| 34: <extension module="org.keycloak.keycloak-server-subsystem"
xmlns=""/>
| ^^^^ 'extension' can't appear more than once within the
extensions element
|
| 35: <extension module="org.keycloak.keycloak-adapter-subsystem"
xmlns=""/>
| 36: <extension module="org.keycloak.keycloak-saml-adapter-subsystem"
xmlns=""/>
| 37: </extensions>
|
| A 'extension' element first appears here:
|
| 33: <extension module="org.wildfly.extension.undertow"/>
| 34: <extension module="org.keycloak.keycloak-server-subsystem"
xmlns=""/>
| 35: <extension module="org.keycloak.keycloak-adapter-subsystem"
xmlns=""/>
| ^^^^
|
| 36: <extension module="org.keycloak.keycloak-saml-adapter-subsystem"
xmlns=""/>
| 37: </extensions>
| 38: <management>
|
| The primary underlying error message was:
| > ParseError at [row,col]:[34,9]
| > Message: WFLYCTL0198: Unexpected element 'extension' encountered
|
|-------------------------------------------------------------------------------
11:13:34,458 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085: Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
at org.jboss.as.server.ServerService.boot(ServerService.java:377)
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:372)
at java.lang.Thread.run(Thread.java:748)
11:13:34,459 FATAL [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting.
See previous messages for details.
11:13:34,470 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050:
WildFly Full 13.0.0.Final (WildFly Core 5.0.0.Final) stopped in 6ms
4 years, 7 months
