All geek questions in one place

Recalculate claims for a SharePoint 2010 user while the user is still registered

I am not a SharePoint expert by any means, and it is very difficult for me to find the right information about this. Please help me!

I need a way to force the claim token set with the call to SPFederationAuthenticationModule.SetPrincipalAndWriteSessionToken to recount the claims on the token without to display the current user. Is there any way to do this?

Some information on why I am asking about this:

We use the user role and membership provider for authN / Z in our SharePoint 2010 user web application. Without going into the details of the reasons (which are complex), the role provider creates dynamically generated role names for the user based on the state of the user in the main application database; these roles represent user permissions and are used internally by SharePoint to determine user access to sites and site collections in an application.

There are ways in our application to change their permissions, effectively adding new roles through the role provider, giving the user additional access to the application. The problem we are facing is that auth, based on the requirements that we have to use in SP2010, pre-issues login permissions and encodes these permissions in session tokens - in fact, it forces us to ask the user to log out and return into the system before they can get their new permissions. This creates all sorts of usability problems, so my question is.

Is there a way to programmatically reconfigure a session token without unloading the user?

Or are we barking the wrong tree? On a normal ASP.NET normal site, I would use Forms Auth, which calculates the authorization for each request, and not at the login. Unfortunately, this is not like an option in SP2010, and I rather stick with SharePoint for now. Are there any other actions we can pursue?

+6
source share
2 answers

Well, after a lot of research caused by @Yahia links, I found the answer to my problems in a blog post . Worked like a charm. Below I will tell below if the connection ever breaks:

The Windows Identify Foundation SessionAuthenticationModule , which is used as the SharePoint 2010 platform, has a great little event that you can call called SessionSecurityTokenReceived , which is called at the beginning of each request. By attaching this event, I can force SharePoint to request an authorization renewal without forcing the user to re-enter credentials.

The code is simple and sweet:

 var sam = sender as SessionAuthenticationModule; var logonWindow = SPSecurityTokenServiceManager.Local.LogonTokenCacheExpirationWindow; var newValidTo = DateTime.UtcNow.Add(logonWindow); e.SessionToken = sam.CreateSessionSecurityToken( e.SessionToken.ClaimsPrincipal, e.SessionToken.Context, e.SessionToken.ValidFrom, newValidTo, e.SessionToken.IsPersistent); e.ReissueCookie = true;

I tested it and the approach definitely works, but there are disadvantages:

  • To call CreateSessionToken need existing data from the current session token, which, it seems, I can only get from the event. This means that this approach can only be implemented in the context of a new request. Since the event fires for every request, and I only want to update auth in certain circumstances, I have to check every request for an invitation to update auth. The easiest approach is to create a magic URL, such as "/ refreshToken? RedirectUrl = {url}", which you check in the event handler. Just redirect to this url when auth is updated and the token needs to be updated.
  • Attracting an event is problematic - you cannot do it statically because the module does not exist when static constructors are built. Ultimately, you are best off doing this in a custom HttpModule or global.asax — both require updating resources that cannot be touched by deploying a .WSP file ( web.config or global.asax ), so any approach causes deployment problems by at least for the first deployment. I chose the global.asax route.

Overall, a satisfactory hack. Done with a minimal workaround.

+5
source

I see several possibilities:

  • try using SPRoleAssignment and SPGroupCollection on respecitve SPUser to dynamically add groups / roles

  • use RenewToken and then ValidateToken
    Regardless of whether this really does what you want, it depends on how the caching is performed (i.e., updates / checks, in turn, cancels the cached requests).

  • save the password in memory, issue a new token (with the same user / pw, but with a new ID!), then call ValidateToken
    I think this is the easiest option, but at the same time a security nightmare (i.e. Bad practice)!

  • call Authenticate when you want to check the application
    Regardless of whether this works, your custom provider depends ... if it works, it will cost performance, though ...

  • implement custom SecurityToken (and provider and ...)
    This will do what you want, but it means a lot of work .

Other useful resources:

+2
source

Source: https://habr.com/ru/post/901147/

More articles:


All Articles