Nick (gagravarr) wrote,

Alfresco WebScripts (Services) and Authentication

I'm currently doing some work on enabling SSO for Alfresco, and I've come across some slightly confused wiki pages and blog posts out there around how webscripts and authentication fits together. As I've done quite a bit of fighting with this in the past, I thought it might be worth trying to summarise what works and why.

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 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.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!
Tags: alfresco

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment