Firstly, WebScript URL prefixes. The Alfresco webscripts are available under three pairs of URL prefixes, also known as WebScript runtimes. As detailed on the wiki, the three are:
/alfresco/service/or/alfresco/s/- HTTP Auth + Tickets, "apiServlet"/alfresco/wcservice/or/alfresco/wcs/- Explorer Style Auth, "wcapiServlet"/alfresco/168service/or/alfresco/168s/- JSR-168 Portlet Auth, "portalapiServlet"
I'll skip the portlet stuff, as I don't use it, and concentrate on the other too. (Note that all three expose the same set of webscripts, it's just the authentication in front of them that changes)
The first thing to note is that describing
/alfresco/service/ as using HTTP Auth misses a few bits out. There are in fact several ways to authenticate to it. One option, most commonly used when debugging and admining, is to use HTTP Basic Auth (but make sure you're using it over SSL in production!). If no other authentication is sent, and the webscript requires it, the webscript framework will prompt you for your username and password with basic auth. Another option is to use Alfresco Tickets, as detailed in the wiki here. You can get a ticket a few different ways, but posting JSON of the username and password to
/alfresco/service/api/login is often the most common. The ticket can be supplied with a request via the alf_ticket URL parameter, or by sending HTTP basic auth with a username of ROLE_TICKET and the ticket as the basic auth password. Another option is to send the URL parameter of guest=true to explicitly request guest access.If you want to see how the authentication to
/alfresco/service/ works, the main class to look at is BasicHttpAuthenticatorFactoryWhen looking at
/alfresco/wcservice/ , most things will describe it as using Explorer authentication. That isn't quite the full story though, if you take a look at web.xml you'll see that there are actually two Authentication Filters that apply to requests through wcservice. The Global Authentication Filter is used (that's the one shared with Explorer), but before that a special WebScript Authentication Filter is also tried.The latter is passed off to a spring bean
webscriptAuthenticationFilter. Not all authentication subsystems implement one of these, so often it'll do nothing. If the authentication filter declines, then it'll fall back to the default Global Authentication Filter, which ends up as the bean globalAuthenticationFilter, and from there the normal Explorer authentication kicks in.Quite a few of the instructions out there for doing SSO involve specifying some custom share config, to change the
alfresco Remote Endpoint to use /wcs . If you see one of these, it will almost always be coupled with changes to your Authentication subsystem(s) to do something with the webscriptAuthenticationFilter. When setting this sort of thing up / debugging, be aware that you'll need to test with /wcs and not /service, and that normally you can't test with Explorer as that doesn't use the same filter! 