All - I am considering the option of removing the topology "service" name from the API resource path.
The current implementation is aligned with all existing patterns for service integrations but seems to pose a more difficult time in naming the topology than it should. Considering that the current service name is knoxsso that is then further qualified with websso - we have a topology naming issue. We have considered things like idp.xml which would result in: https://localhost:8443/gateway/sandbox/idp/knoxsso/api/v1/websso This sort of works but idp isn't really accurate in that this is a federation provider that facilitates token exchange with various SSO provider integrations. Moreover, the service name seems to call out the behavior and if it truly is facilitating *the* single sign on integration for an enterprise then it is redundant. So, the initial thought was to eliminate the use of a specific service name within the resource path and just name the topology appropriately. More like: https://localhost:8443/gateway/sandbox/knoxsso/api/v1/websso If there is only one then this makes a lot of sense. However, if we need to provide another version of SSO for say REST APIs where cookies may not be used then we will need to either accommodate both in the same knoxsso.xml topology or deploy another with different federation capabilities. For instance: https://localhost:8443/gateway/sandbox/knoxsso-rest/api/v1/websso This seems to hold together but also strikes me odd that both of these "top level services" (meaning no service name?) have the same API. I guess the question is whether we want to be strict about resource naming here? It seems that simplifying it this way might make the actual resource - which is a token exchange mechanism - be ambiguous which feels wrong. If this is wrong then we go back to having the topology naming to wrestle with. Perhaps the following isn't so bad: https://localhost:8443/gateway/sandbox/auth-ui/knoxsso/api/v1/websso https://localhost:8443/gateway/sandbox/auth-rest/knoxsso/api/v1/websso Thoughts? thanks, --larry
