I noticed this bullet point for the upcoming release of alfresco-js-api 1.3.0:
This is then backed up by this commit:
From these, I discovered this documentation:
These docs are a good start, but they definitely need a bunch more love .
From the architecture diagram and some of the text it appears that this can authenticate against content services and also possibly perform proxying to content and process services in addition to handling most of the oauth flows. We can infer from the config parameters that this is using Netflix Zuul to perform proxying/routing. Can we use this to serve directly or proxy to ADF apps? Can we use this to perform any kind of intelligent load balancing for content or process services? Does this allow us to get away from the "CORS hell" we've been in for the last year?
It is not clear to me how this “micro service” integrates with content services. Should we run it in it's own app server, in the content services or process services app server?
It is not clear if we can use this to authorize access to Share or only Process Services (and soon alfresco-js-api, and presumably ADF apps.) The docs seem to indicate that the identity is actually maintained by content services. Other than providing a URL for process services, I couldn't find any information about how these components interact with each other. How does Alfresco Authorization Server establish your identity from the repository? Do we have to do any configuration on the repository side?
The docs do link to a WAR file on artifacts.alfresco.com. This artifact requires Alfresco Process Services Enterprise credentials. Why is this tied to Process Services if it's going to be used by ADF (and hopefully Share)? Is this going to be made away to folks using the community edition of content or process services? ADF can be used with the community edition of content services at this point, even though it can't yet be used with the community version of process services.
The docs indicate that a third party OAuth2 provider (Ping Identity is suggested, what about Google Auth?) can be utilized by Alfresco Process Services. This part of the diagram appears to bypass the Alfresco Authorization Server. If this server provides useful proxying support for ADF or any kind of other intelligent routing, I wonder if it would be possible for the third party identity provider to relay through the Alfresco Authorization Server?
Any chance that Alfresco Authorization Server has (or will add) support for non OAuth2 SSO providers (AD/LDAP, CAS, external, Kerberos, NTLM, SAML2, SiteMinder)? It would be amazing to have a single (hopefully well documented) component providing comprehensive Authorization services to the Alfresco product portfolio; so we can configure auth once and have it work the same with Content Services, Share, Process Services and ADF apps.
In any case, I'm very excited about some of the possible use cases with adding native OAuth2 capabilities to the Alfresco portfolio and I'm looking forward to hearing more about the existing capabilities and also any plans for the future.
What others in the community are thinking about these developments?
I would certainly welcome some work in this area for content services
My observations are that non standard auth is pretty fragile, and probably not well understood, at the moment as it seems to break with most new releases.
I made some comments in this JIRA [ALF-21848] Improve support for third party SSO via web-fragment.xml - Alfresco JIRA but this is only tweaking the current implementation.
AFAIK the current SAML work is for Enterprise only, I haven't heard about any OAuth work but that would be interesting as I think I might be able to set CAS up as an OAuth provider and could retire my CAS work which would be nice!
There seems to be an expectation that basic-auth will be used e.g. by mobile clients, ADF, CMIS and if SSO is introduced to the platform end points then that will be broken (rumour has it the internal instance can't be accessed via mobile)
(I have a nasty hack in my CAS amps to get around this)
I don't think that SSO has been properly considered in the context of ADF - I expect to be able to make it work but haven't had the time yet - from what I understand it's relying heavily on using a ticket after basic-auth, which isn't great.
Interesting comment
The server needs to be used in conjunction with the LDAP sync for users from the Alfresco Content Services LDAP directory.
I can't see why this would be the case
Mario RomanoKristen Gastaldo Francesco Corti Any chance this thread could get some insight from Alfresco folks or a pointer to somewhere else where these items are covered?
I think this one snuck by, as discussions don't seem to get the coverage questions do. I'll send this to a few employees for some insight.
I spoke, briefly, to Brian Remington about SSO at BeeCon and apparently SSO is somewhere near the top of his list.
However I got the impression that it's more to do with SSO between content services and process services than external SSO providers. (external SSO is a very strong requirement for me)
OpenID connect did come up as part of the discussion so it's possible external authentication providers will also be included.
We did, again very briefly, talk about the problems with external authorization (what you can do/group membership) as well as authentication (who you are) - for the record I'm happy with authentication and using the LDAP sync for the overlapping authorization (despite some problems with it e.g. [ACE-5679] Indirect groups no longer work as site manager - Alfresco JIRA )
Do you have some additional information on the topic?
We would like to use oauth2 with Content Services in Community Edition.
Sorry, I was asked a few times to respond but didn't get it done.
This discussion brings together a few separate engineering projects:
I mention these on the to explain the direction we are headed, but I'm not yet in a position to provide details as we are still experimenting in order to find the best approach.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.