Hi Johann, > >> In SCIM 2.0 compliance test suite, there are inter dependencies between >> tests. For an example, >> >> We have identified /Schemas endpoint as a critical test which tests the >> schemas corresponding to user and group resources according to SCIM >> specification. However in a case where a SCIM service provider has >> customized the schemas according to their own requirements, this test will >> be failed. As the test suite uses the /Schemas endpoint to learn about the >> service providers schema definitions (consider the case where there is a >> user schema extension defined by the service provider), if the /Schemas >> endpoint fails, the test suite will be terminated immediately as the test >> suite cannot learn the configurations. However we can also make it not to >> terminate but to get adjusted to the service provider's configs after just >> failing the /Schemas endpoint test only. With that, the service provider >> will be able to run the remaining tests on the altered schemas without >> being blocked due to test dependency. But it should also be noted that, >> this approach can cause the test suite to not to adhere to the >> specification, but to adjust itself dynamically after a proper indication >> of the reason for the adjustment. >> >> Hence, as identified in the above example, there are two possible options >> in a test dependency situation. >> >> 1. Terminate >> 2. Adjust accordingly and continue the suite but fails only the parent >> test. >> >> What is the best way of handling this?. Any thoughts on this is highly >> appreciated. >> > > I would say just terminate. Why would you need to customize the core user > schema when there is the possibility of defining an extended user schema. > No one asked you to stick to any of the attributes coming from the core > schema right? >
Yes, you have a good point on this. Assuming user schema can be done in the way you have specified, still there can be a problem when it comes to group schema since it does not have an extension defined. However due to the less number of attributes associated with the group schema and their nature of it, I would say, it is very likely that service providers will not be altering the group schema most of the cases. Hence putting an effort on the second option could be redundant. So I agree with the termination based on your reasoning. > > >> >> Thank you >> *Vindula Jayawardana* >> Computer Science and Engineering Dept. >> University of Moratuwa >> mobile : +713462554 >> Email : [email protected] >> >> <https://www.facebook.com/vindula.jayawardana> >> <http://lk.linkedin.com/pub/vindula-jayawardana/a7/315/53b> >> <https://plus.google.com/u/0/+VindulaJayawardana/posts> >> <https://twitter.com/vindulajay> >> >> *“Respect is how to treat everyone, not just those you want to impress. "* >> >> >> *-Richard Branson-* >> >> >> > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Senior Technical Lead - WSO2 Identity Server > Governance Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
