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/s/- HTTP Auth + Tickets, "apiServlet"
/alfresco/wcs/- Explorer Style Auth, "wcapiServlet"
/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/loginis often the most common. The ticket can be supplied with a request via the
alf_ticketURL parameter, or by sending HTTP basic auth with a username of
ROLE_TICKETand the ticket as the basic auth password. Another option is to send the URL parameter of
guest=trueto explicitly request guest access.
If you want to see how the authentication to
/alfresco/service/works, the main class to look at is BasicHttpAuthenticatorFactory
When 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.xmlyou'll see that there are actually two Authentication Filters that apply to requests through wcservice. The
Global Authentication Filteris used (that's the one shared with Explorer), but before that a special
WebScript Authentication Filteris 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
alfrescoRemote 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!