I am modifying an existing system that uses SharePoint 2013 with Forms-Based Authentication (FBA) to allow users to self-service creation of accounts and management of the accounts. One of the things they can manage is role membership; effectively, they are given a role access code which they supply to the system, and it adds them to the role, allowing them to access sites which the role has been granted access to. Part of the solution is a custom login screen to help support all of this and make it more user friendly. All of this is working relatively well.
The task I am working on it adding support for external authentication providers rather than the forms-based authentication - this is a business requirement. There is plenty of online information (e. g. http://blogs.msdn.com/b/mvpawardprogram/archive/2011/06/17/mvps-for-sharepoint-2010-using-azure-acs-v2-to-authenticate-external-systems-users.aspx) on how to add Azure ACS as an identity provider and that's working. The issue is now how to add the self-service role authorization piece.
I've gotten simple claims augmentation working fine following the guide at http://www.microsoft.com/en-us/download/details.aspx?id=27569. The problem I'm hitting is the "common" issue of the in-box STS doing caching on the token, so when a user's role membership is changed, they get the old cached token still. My claims augmentation code isn't called (of course not - why would it be when the STS is using a cached ticket), so the change in membership isn't being seen.
This is pretty much the same kind of issue discussed at check permissions showing incorrect information and http://www.shillier.com/archive/2010/10/25/authorization-failures-with-claims-based-authentication-in-sharepoint-2010.aspx, with the common answer of changing the token lifetime given. I have a few issues with and questions about this.
In the external claims scenario, what is the lifetime applied? It's not a Windows token, and it's not an FBA token, so neither
FormsTokenLifetimeseem appropriate, although those are the two everyone says to change.
I don't want the token to expire for the end user in an unreasonably short time, I just want the STS to expire the cached version or ideally never cache it at all (I know there's a performance issue there - I don't care, for our scale it won't matter). It seems like those two things are coupled, though. Is there a way to decouple them?
If I can't decouple, is there a way for the login screen to indicate to the system that I want the claim to be re-augmented? Can I just to it myself by modifying the current user identity? That's going behind the system's back of course so I don't want to do that if I can help it.
All of this seems to ultimately come down to the caching in the OOB STS since all of the other moving parts seem to be right. Is the "right" way to avoid this to create a custom STS that doesn't have the caching behavior and register it as an identity provider? (If I have a custom STS it seems like I wouldn't bother with claims augmentation at that point, I'd just issue all the proper claims in the first place.) That seems like a substantial amount of work though (although I know there are samples including http://archive.msdn.microsoft.com/SelfSTS), especially since it seems like I've have to hook up the relying party connection to Azure ACS then as part of the process, where the OOB STS does that "magically" with a few lines of PowerShell and some effort.
Or, do I need to abandon claims and simply change the FBA side? That feels like a horrible way to go since now I need to hook up all of the OpenID stuff in my authentication code for FBA, and I'm moving backwards away from claims when I know I should be moving to claims.
A delay of say 60 minutes is simply not acceptable when in the FBA model I can make the change immediately by forcing the user to sign in again, which gets the new role membership.