[JBoss JIRA] (GTNSSO-29) Implement SPNEGO SSO for gatein-tomcat packaging
by Tuyen Nguyen The (JIRA)
Tuyen Nguyen The created GTNSSO-29:
--------------------------------------
Summary: Implement SPNEGO SSO for gatein-tomcat packaging
Key: GTNSSO-29
URL: https://issues.jboss.org/browse/GTNSSO-29
Project: GateIn SSO
Issue Type: Feature Request
Reporter: Tuyen Nguyen The
Assignee: Marek Posolda
Current spnego sso implementation of gatein only works on jboss because it use Jboss Negotiation library - a specific library for jboss.
So, we need provide other implementation for gatein-tomcat packaging.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3495) Membership Pagination don't work
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3495?page=com.atlassian.jira.pl... ]
Marek Posolda commented on GTNPORTAL-3495:
------------------------------------------
Option "skipPaginationInMembershipQuery" can be switched to false for improving performance, but that's jut for DB-Only setup. For mixed (DB+LDAP) it should be kept to true to have accurate results.
Pagination of memberships can't be enabled with DB+LDAP because you can have part of users (and their memberships) just in DB, part of them just in LDAP, and part in both. So pagination+sorting is not intended to work. Plain pagination theoretically might work for some LDAP servers, which support pagination extension ( http://www.ietf.org/rfc/rfc2696.txt ) but that's not supported ATM and even if it's implemented in Picketlink IDM, results might not be accurate for DB+LDAP and some memberships will be duplicated.
> Membership Pagination don't work
> --------------------------------
>
> Key: GTNPORTAL-3495
> URL: https://issues.jboss.org/browse/GTNPORTAL-3495
> Project: GateIn Portal
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5.9.Final
> Reporter: Boubaker Khanfir
> Assignee: Marek Posolda
> Attachments: plidm-ldap-membership-pagination.zip
>
>
> I attach a new unit test for a bug that I met in PL IDM 1.4.4.
> Test case description:
> 1/ add about 10 users in an LDAP group
> 2/ use SearchCriteria to paginate on the Members of this group
> => Problem: pagination doesn't work
> Why does it fails:
> Because in this method "org.picketlink.idm.impl.store.ldap.LDAPIdentityStoreImpl.resolveRelationships(IdentityStoreInvocationContext, IdentityObject, IdentityObjectRelationshipType, boolean, boolean, String, IdentityObjectSearchCriteria)" the attribute "IdentityObjectSearchCriteria" isn't used for pagination.
> To workaround this bug I had to use (skipPaginationInMembershipQuery=true). If the UI is buggy without this parameter to "true", I think it has to be *by default "true" in Config class* and may be even delete this option to not use pagination in Membership at all.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3495) Membership Pagination don't work
by Boubaker Khanfir (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3495?page=com.atlassian.jira.pl... ]
Boubaker Khanfir commented on GTNPORTAL-3495:
---------------------------------------------
Yes, I know the default value is set to true. Sorry for the copy/paste in TestCase, but the first one attached in jbossexo ML didn't get the same page. Anyway, did you reproduce the problem using skipPaginationInMembershipQuery=false? (After test case change)
> Membership Pagination don't work
> --------------------------------
>
> Key: GTNPORTAL-3495
> URL: https://issues.jboss.org/browse/GTNPORTAL-3495
> Project: GateIn Portal
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5.9.Final
> Reporter: Boubaker Khanfir
> Assignee: Marek Posolda
> Attachments: plidm-ldap-membership-pagination.zip
>
>
> I attach a new unit test for a bug that I met in PL IDM 1.4.4.
> Test case description:
> 1/ add about 10 users in an LDAP group
> 2/ use SearchCriteria to paginate on the Members of this group
> => Problem: pagination doesn't work
> Why does it fails:
> Because in this method "org.picketlink.idm.impl.store.ldap.LDAPIdentityStoreImpl.resolveRelationships(IdentityStoreInvocationContext, IdentityObject, IdentityObjectRelationshipType, boolean, boolean, String, IdentityObjectSearchCriteria)" the attribute "IdentityObjectSearchCriteria" isn't used for pagination.
> To workaround this bug I had to use (skipPaginationInMembershipQuery=true). If the UI is buggy without this parameter to "true", I think it has to be *by default "true" in Config class* and may be even delete this option to not use pagination in Membership at all.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3495) Membership Pagination don't work
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3495?page=com.atlassian.jira.pl... ]
Marek Posolda commented on GTNPORTAL-3495:
------------------------------------------
Few comments about this:
1) Your test is not correct as it always read just page1 (memberships.load(0, 5);), so it return it always same results for both call, hence it's not surprising that results are duplicated. I've changed the code of the method "testMembership" like this:
{code}
@Test
public void testMembership() throws Exception {
ExoContainer container = PortalContainer.getInstance();
OrganizationService service = (OrganizationService) container.getComponentInstance(OrganizationService.class);
MembershipHandler handler = service.getMembershipHandler();
Group group = service.getGroupHandler().findGroupById("/test/developers");
ListAccess<Membership> memberships = handler.findAllMembershipsByGroup(group);
Set<String> identities = new HashSet<String>();
int counter = 0;
int pageNumber = 0;
while (counter < memberships.getSize()) {
int remaining = memberships.getSize() - counter;
int currentPageCount = Math.min(remaining, 5);
Membership[] membershipsPage = memberships.load(counter, currentPageCount);
counter += currentPageCount;
for (Membership membership : membershipsPage) {
identities.add(membership.getUserName());
}
System.out.println("Loaded page: " + ++pageNumber + " with " + currentPageCount + " records.");
}
System.out.println("All loaded members: " + identities);
// Assert same count, so no identities has been filtered
assertEquals(identities.size(), memberships.getSize());
}
{code}
And now there are 11 memberships in LDAP and all those are properly read in 3 pages (page1 has 5 items, page2 has 5 items and last page just remaining 1 item) and displayed.
2) Parameter "skipPaginationInMembershipQuery" already has default value "true" as you can see here: https://github.com/gatein/gatein-portal/blob/master/web/portal/src/main/w... . I don't think that it should be removed because for DB-only setup, it can be used to improve performance as with non-mixed (DB only) setup, it's safe to use paginated query in IDM. Unfortunately for mixed DB+LDAP setup, pagination can't be safely used due to reasons, which Bolek already mentioned by email.
> Membership Pagination don't work
> --------------------------------
>
> Key: GTNPORTAL-3495
> URL: https://issues.jboss.org/browse/GTNPORTAL-3495
> Project: GateIn Portal
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5.9.Final
> Reporter: Boubaker Khanfir
> Assignee: Marek Posolda
> Attachments: plidm-ldap-membership-pagination.zip
>
>
> I attach a new unit test for a bug that I met in PL IDM 1.4.4.
> Test case description:
> 1/ add about 10 users in an LDAP group
> 2/ use SearchCriteria to paginate on the Members of this group
> => Problem: pagination doesn't work
> Why does it fails:
> Because in this method "org.picketlink.idm.impl.store.ldap.LDAPIdentityStoreImpl.resolveRelationships(IdentityStoreInvocationContext, IdentityObject, IdentityObjectRelationshipType, boolean, boolean, String, IdentityObjectSearchCriteria)" the attribute "IdentityObjectSearchCriteria" isn't used for pagination.
> To workaround this bug I had to use (skipPaginationInMembershipQuery=true). If the UI is buggy without this parameter to "true", I think it has to be *by default "true" in Config class* and may be even delete this option to not use pagination in Membership at all.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3495) Membership Pagination don't work
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3495?page=com.atlassian.jira.pl... ]
Marek Posolda reassigned GTNPORTAL-3495:
----------------------------------------
Assignee: Marek Posolda
> Membership Pagination don't work
> --------------------------------
>
> Key: GTNPORTAL-3495
> URL: https://issues.jboss.org/browse/GTNPORTAL-3495
> Project: GateIn Portal
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5.9.Final
> Reporter: Boubaker Khanfir
> Assignee: Marek Posolda
> Attachments: plidm-ldap-membership-pagination.zip
>
>
> I attach a new unit test for a bug that I met in PL IDM 1.4.4.
> Test case description:
> 1/ add about 10 users in an LDAP group
> 2/ use SearchCriteria to paginate on the Members of this group
> => Problem: pagination doesn't work
> Why does it fails:
> Because in this method "org.picketlink.idm.impl.store.ldap.LDAPIdentityStoreImpl.resolveRelationships(IdentityStoreInvocationContext, IdentityObject, IdentityObjectRelationshipType, boolean, boolean, String, IdentityObjectSearchCriteria)" the attribute "IdentityObjectSearchCriteria" isn't used for pagination.
> To workaround this bug I had to use (skipPaginationInMembershipQuery=true). If the UI is buggy without this parameter to "true", I think it has to be *by default "true" in Config class* and may be even delete this option to not use pagination in Membership at all.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema validation for gatein-resources.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3501?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-3501:
----------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1103771|https://bugzilla.redhat.com/show_bug.cgi?id=1103771] from ASSIGNED to MODIFIED
> Introduce XML schema validation for gatein-resources.xml
> --------------------------------------------------------
>
> Key: GTNPORTAL-3501
> URL: https://issues.jboss.org/browse/GTNPORTAL-3501
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> There are several lines of code that indicate that {{org.exoplatform.commons.xml.XMLValidator}} was originally designed to check if a given document complies with an XML schema declared in it:
> {code:java}
> factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaSource", schemas);
> factory.setNamespaceAware(true);
> factory.setValidating(true);
> {code}
> However, there were no tests checking if the validation works and indeed, it does not. It is out of the present scope to investigate what is wrong with {{XMLValidator}} and how it can be corrected, because it is too general to be used for validating {{gatein-resources.xml}} at this point. The main problem is that if we have not validated so far, there must be a lot of schema-incompatible {{gatein-resources.xml}} out there in the wild that were silently accepted by the portal in the past. Therefore, we cannot start validating all {{gatein-resources.xml}} files now.
> To meet the natural expectation that inputs are properly validated to widest possible extent, I propose to start validating now, but only {{gatein-resources.xml}} documents that use the namespace {{http://www.gatein.org/xml/ns/gatein_resources_1_5}} or newer. {{gatein_resources_1_5.xsd}} will be introduced these days with fixing
> GTNPORTAL-3485 and GTNPORTAL-3487. In this way we can stay backwards-compatible and start validating from now on.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema validation for gatein-resources.xml
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3501?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration updated GTNPORTAL-3501:
-----------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103771
> Introduce XML schema validation for gatein-resources.xml
> --------------------------------------------------------
>
> Key: GTNPORTAL-3501
> URL: https://issues.jboss.org/browse/GTNPORTAL-3501
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> There are several lines of code that indicate that {{org.exoplatform.commons.xml.XMLValidator}} was originally designed to check if a given document complies with an XML schema declared in it:
> {code:java}
> factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaSource", schemas);
> factory.setNamespaceAware(true);
> factory.setValidating(true);
> {code}
> However, there were no tests checking if the validation works and indeed, it does not. It is out of the present scope to investigate what is wrong with {{XMLValidator}} and how it can be corrected, because it is too general to be used for validating {{gatein-resources.xml}} at this point. The main problem is that if we have not validated so far, there must be a lot of schema-incompatible {{gatein-resources.xml}} out there in the wild that were silently accepted by the portal in the past. Therefore, we cannot start validating all {{gatein-resources.xml}} files now.
> To meet the natural expectation that inputs are properly validated to widest possible extent, I propose to start validating now, but only {{gatein-resources.xml}} documents that use the namespace {{http://www.gatein.org/xml/ns/gatein_resources_1_5}} or newer. {{gatein_resources_1_5.xsd}} will be introduced these days with fixing
> GTNPORTAL-3485 and GTNPORTAL-3487. In this way we can stay backwards-compatible and start validating from now on.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for JavaScript and skin services
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3502?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-3502:
----------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1103768|https://bugzilla.redhat.com/show_bug.cgi?id=1103768] from NEW to MODIFIED
> Commnon deployer for JavaScript and skin services
> -------------------------------------------------
>
> Key: GTNPORTAL-3502
> URL: https://issues.jboss.org/browse/GTNPORTAL-3502
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> At present, there are two independent deployers for JavaScript and skin services: {{GateInSkinConfigDeployer}} and {{JavascriptConfigDeployer}}. There are two problems with that:
> (1) Both of them parse {{gatein-resources.xml}} independently, which is a performance drawback.
> (2) They can succeed or fail independently, e.g. in case there is some meaningless declaration in {{gatein-resources.xml}}, which can lead to an inconsistent state of the portal.
> An ideal solution for (2) would be to rollback deployment of the whole web application, but unfortunately, the present design of the portal does not allow for that. Therefore, I propose to keep at least the two services consistent by introducing a common deployer, that will grant that resources will either succeed to be added to both or to none. Problem (1) will be solved by that too.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for JavaScript and skin services
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3502?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration updated GTNPORTAL-3502:
-----------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103768
> Commnon deployer for JavaScript and skin services
> -------------------------------------------------
>
> Key: GTNPORTAL-3502
> URL: https://issues.jboss.org/browse/GTNPORTAL-3502
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Peter Palaga
> Assignee: Peter Palaga
> Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> At present, there are two independent deployers for JavaScript and skin services: {{GateInSkinConfigDeployer}} and {{JavascriptConfigDeployer}}. There are two problems with that:
> (1) Both of them parse {{gatein-resources.xml}} independently, which is a performance drawback.
> (2) They can succeed or fail independently, e.g. in case there is some meaningless declaration in {{gatein-resources.xml}}, which can lead to an inconsistent state of the portal.
> An ideal solution for (2) would be to rollback deployment of the whole web application, but unfortunately, the present design of the portal does not allow for that. Therefore, I propose to keep at least the two services consistent by introducing a common deployer, that will grant that resources will either succeed to be added to both or to none. Problem (1) will be solved by that too.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months