[JBoss JIRA] (WFLY-5740) ContextPolicy checks purely based on names, ignores Principal types
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-5740?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-5740.
------------------------------------
Assignee: Darran Lofthouse (was: Pedro Igor)
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketBox which is deprecated.
> ContextPolicy checks purely based on names, ignores Principal types
> -------------------------------------------------------------------
>
> Key: WFLY-5740
> URL: https://issues.jboss.org/browse/WFLY-5740
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR4
> Reporter: Arjan t
> Assignee: Darran Lofthouse
> Priority: Major
>
> In {{org.jboss.security.jacc.ContextPolicy}} the {{implies}} method only looks at the names of each {{Principal}} from the passed in {{ProtectionDomain}}, without checking if they're actually a role.
> The collection of these names is then used to check against role based permissions.
> If a user now has a name "expert" and there's also a role called "expert", access will be granted purely based on the user (caller) name. This is of course not correct.
> See the following code:
> {code:java}
> // Check principal to role permissions
> Principal[] principals = domain.getPrincipals();
> int length = principals != null ? principals.length : 0;
> ArrayList<String> principalNames = new ArrayList<String>();
> for (int n = 0; n < length; n ++) {
> Principal p = principals[n];
> if( p instanceof Group ) {
> Group g = (Group) p;
> Enumeration<? extends Principal> iter = g.members();
> while(iter.hasMoreElements()) {
> p = iter.nextElement();
> // *** ONLY NAME IS USED. TYPE IS IGNORED
> String name = p.getName();
> principalNames.add(name);
> }
> }
> else {
> String name = p.getName();
> // *** ONLY NAME IS USED. TYPE IS IGNORED
> principalNames.add(name);
> }
> }
> principalNames.add(ANY_AUTHENTICATED_USER_ROLE);
> for (int n = 0; implied == false && n < principalNames.size(); n ++) {
> String name = principalNames.get(n);
> // *** "name", WHICH CAN BE ANYTHING, USED FOR ROLE NAME HERE
> Permissions perms = rolePermissions.get(name);
> if( perms == null )
> continue;
> implied = perms.implies(permission);
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-629:
---------------------------------------
Assignee: Darran Lofthouse (was: Peter Skopek)
> Enabled automatic encryption of passwords stored in configuration
> -----------------------------------------------------------------
>
> Key: WFCORE-629
> URL: https://issues.jboss.org/browse/WFCORE-629
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management, Security
> Environment: Wildfly 9
> Reporter: Jason Shepherd
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 8.0.0.Beta2
>
>
> Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration.
> It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ]
Darran Lofthouse updated WFCORE-629:
------------------------------------
Fix Version/s: 8.0.0.Beta2
> Enabled automatic encryption of passwords stored in configuration
> -----------------------------------------------------------------
>
> Key: WFCORE-629
> URL: https://issues.jboss.org/browse/WFCORE-629
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management, Security
> Environment: Wildfly 9
> Reporter: Jason Shepherd
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 8.0.0.Beta2
>
>
> Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration.
> It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFCORE-2146) Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-2146?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2146.
--------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Do
Marked as 'Won't Do' as security realms are deprecated so we will not be adding any future enhancements.
> Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-2146
> URL: https://issues.jboss.org/browse/WFCORE-2146
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Environment: CentOS release 6.8 (Final)
> JBoss Admin Command-line Interface
> JBOSS_HOME: /opt/wildfly/10.1.0
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: null
> java.version: 1.8.0_40
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.40-b25
> os.name: Linux
> os.version: 4.6.3-1.el6.elrepo.x86_64
> Reporter: Daniel Draper
> Assignee: Darran Lofthouse
> Priority: Major
>
> When hooking up our Wildfly Application to our SSO (CAS) for authentication and delegating Authorization to a Security Realm and then using LDAP we ran into the following problem:
> *Use Case*
> We want to use authorization inside a Security-Realm through LDAP.
> In our LDAP setup we have a Group-To-Principal matching of the form "_member=uid=x" OR "submember=uid=x_" depending on if the user was added manually or through an autodomain.
> Unfortunately as far as we could tell using two attributes in the Polish Notation (as is required by [LDAP|https://ldapwiki.com/wiki/LDAP%20filters%20Syntax%20and%20Choices]) seems to be impossible for the wildfly configuration. We tried the following in the standalone-accounting.xml (in different iterations and ways to place the parenthesis) which all lead to an 'unbalanced Parenthesis' or similar error when starting up wildfly.
> {code:xml}
> <management>
> <security-realms>
> <security-realm name="bla">
> <authorization>
> <ldap connection="ldap">
> <username-to-dn>
> <username-is-dn/>
> </username-to-dn>
> <group-search group-name="SIMPLE" iterative="false" group-dn-attribute="cn" group-name-attribute="cn">
> <group-to-principal search-by="SIMPLE" base-dn="ou=roles,***" recursive="false">
> <membership-filter principal-attribute="|(submember=uid={0})(member=uid={0})"/>
> </group-to-principal>
> </group-search>
> </ldap>
> </authorization>
> </security-realm>
> </security-realms>
> </management>
> {code}
> We then found the filterString is parsed the following way: (See [LdapGroupSearcherFactory#L115|https://github.com/wildfly/wildfly-core/blo...])
> {code:java}
> this.filterString = String.format("(%s={0})", principalAttribute);
> {code}
> which seems to make multiple attribute names as a filter impossible, which makes our use case as above impossible.
> Asked in [Forums|https://developer.jboss.org/thread/273435], but since I didn't get any answers for 3 weeks opening here.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-8301) Picketlink trust domain config needs to be in attribute and not path
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-8301?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-8301.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketLink which is deprecated.
> Picketlink trust domain config needs to be in attribute and not path
> --------------------------------------------------------------------
>
> Key: WFLY-8301
> URL: https://issues.jboss.org/browse/WFLY-8301
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomaz Cerar
> Assignee: Darran Lofthouse
> Priority: Major
>
> Currently trustdomain for PL federation is configured by adding new sub resource under idenity-provider
> Problem is that name of the trust domain resource you add is an url.
> In case that URL is ipv6 one in square brackets [::1] this makes it a invalid path.
> Currently testsuite relies on this to work, and by some miracle it works when configured via XML, but trying to do so with CLI fails as [] are forbidden chars in path (resource name)
> example of CLI command
> {{/subsystem=picketlink-federation/federation=federation-simple-redirect-binding/identity-provider=idp-redirect.war/trust-domain=${public.ip}:add
> /subsystem=picketlink-federation/federation=federation-redirect-with-signatures/identity-provider=idp-redirect-sig.war/trust-domain=${public.ip}:add
> /subsystem=picketlink-federation/federation=federation-simple-post-binding/identity-provider=idp-post.war/trust-domain=${public.ip}:add
> /subsystem=picketlink-federation/federation=federation-post-with-signatures/identity-provider=idp-post-sig.war/trust-domain=${public.ip}:add
> /subsystem=picketlink-federation/federation=federation-with-metadata/identity-provider=idp-metadata.war/trust-domain=${public.ip}:add}}
> where ${public.ip} can be 127.0.01 or [::1]
> I think given that TrustDomainResourceDefinition has no attributes beyond own name.
> it could be converted to a List<String> on parent resource.
> or name should be used only for id, with additional attribute that would represent domain.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-8300) standalone-picketlink.xml boots with lots of errors
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-8300?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-8300.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketLink which is deprecated.
> standalone-picketlink.xml boots with lots of errors
> ---------------------------------------------------
>
> Key: WFLY-8300
> URL: https://issues.jboss.org/browse/WFLY-8300
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomaz Cerar
> Assignee: Darran Lofthouse
> Priority: Major
>
> If you try to run standalone-picketlink.xml server configuration, it's boot fails with lots of problems. They look related to elytron changes, but I am not sure.
> {noformat}
> 15:27:36,476 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "picketlink-identity-management"),
> ("partition-manager" => "jpa.emf.modules.partition.manager")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store" => "org.jboss.msc.service.StartException in service jb
> oss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store: Failed to start service
> Caused by: org.picketlink.idm.config.SecurityConfigurationException: WFLYPL0050: Entities module not found [my.module]."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.picketlink-identity-management.\"jpa.emf.modules.partition.manager\".\"jpa.config\".jpa-store"]
> }
> 15:27:36,477 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("setting" => "http-invoker")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.http-authentication-factory.application-http-authentication"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.undertow.server.default-server.default-host.http-invoker is missing [org.wildfly.security.http-authentication-factory.
> application-http-authentication]"]
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-7096) Security domain casche dosn't respect infinispan settings
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-7096?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-7096.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketBox which is deprecated.
> Security domain casche dosn't respect infinispan settings
> ---------------------------------------------------------
>
> Key: WFLY-7096
> URL: https://issues.jboss.org/browse/WFLY-7096
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Environment: Tested on Windows 7
> Reporter: Marcin Fatyga
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: patch.txt, standalone.xml, test_webapp.zip
>
>
> In securitydomain we can set "casche-type" to infinispan. Auntentication request ara now stored in infinispan casch, but any settings of this casche (configured in infinispan subsystem) are not applied. Casche is always stored in memory and never expiries.
> This is serious security issue because after first authentication request credentials, will never be verified again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (WFLY-6535) LdapLoginModule authentication fails when some part of DN is part of LDAP URL
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFLY-6535?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse resolved WFLY-6535.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Won't Fix
Marking as 'Won't Fix' as this is in relation to PicketBox which is deprecated.
> LdapLoginModule authentication fails when some part of DN is part of LDAP URL
> -----------------------------------------------------------------------------
>
> Key: WFLY-6535
> URL: https://issues.jboss.org/browse/WFLY-6535
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Major
>
> In case when part of DN is placed in LDAP URL instead of principalDNSuffix then authentication fails (see [1] for details about this URL) in LdapLoginModule. Authentication is provided by binding with user DN and password, but in this case user DN does not include DN part from LDAP URL which leads to fail.
> Thrown exception:
> {code}
> javax.naming.AuthenticationException: LDAP: error code 49 - INVALID_CREDENTIALS: Bind failed: ERR_229 Cannot authenticate user uid=jduke,ou=People
> com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3135)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3081)
> com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2883)
> com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2797)
> com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> javax.naming.InitialContext.init(InitialContext.java:244)
> javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> org.jboss.security.auth.spi.LdapLoginModule.createLdapInitContext(LdapLoginModule.java:362)
> org.jboss.security.auth.spi.LdapLoginModule.validatePassword(LdapLoginModule.java:289)
> org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> {code}
> [1] https://tools.ietf.org/html/rfc2255
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months