Yesterday I went trough and interesting analysis with Matias about how is the best way to tweak the SAML Token Lifetime for Sharepoint 2010 web applications using ADFS as a Claims Auth provider.

We have basically three cookies to worry about in this scenario. The Authentication cookie, the Account partner cookie and the SharePoint cookie.  The Account partner cookie is the one that bypasses the home realm discovery page when we hit ADFS and is not involved in this scenario.

The Authentication cookie has two associated lifetimes, the SSOLifeTime and the TokenLifetime for an specific Relying Party. You can change the TokenLifetime using the following powershell script.

Add-PSSnapin Microsoft.ADFS.Powershell

Set-ADFSRelyingPartyTrust -TargetName “Relying Party Common Name” -TokenLifeTime 15

On the Sharepoint side there is also a configuration that needs to be considered which is the LogonTokenCacheExpirationWindow, that value  needs to be understood as a time windows that Sharepoint considers before the SAML token will expire to renew the token. The LogonTokenCacheExpirationWindow needs always to be much less than the TokenLifeTime if both values are similar You basically go back and forth until ADFS stops and gives you the error message “The same client browser session has made ‘6’ requests in the last ‘12’ seconds.”. This is because as soon as Sharepoint received the SAML token for ADFS it knows that the cookie was good for less time than the  LogonTokenCacheExpirationWindow so it went back to ADFS to authenticate again.

We tried different values for this setting and we think that 1 second is enough for that time windows. Making this windows as small as possible will push the management to ADFS.

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan –minutes 1)

$sts.Update()

iisreset

Reference: http://blogs.technet.com/b/speschka/archive/2010/08/09/setting-the-login-token-expiration-correctly-for-sharepoint-2010-saml-claims-users.aspx we found this post very useful it will give you a deeper look at the problem.

How to configure Sharepoint to call the wa=wsignout1.0 action?

1. You need to modify the Welcome.ascx page on C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES\ on every front-end server that hosts this web application.
2. Find the section
   id="ID_Logout2"
3. Modify that section to id=”ID_Logout2” and then add the ClientOnClickNavigateUrl attribute to point to your ADFS
   
4. Now when you click the Sign-Out button on Sharepoint 2010 you will be redirected to ADFS,
   

Identified Caveats

1. Kerberos ticket will not expire: Although you logged-out from ADFS you will not be able to login as a different domain user unless you close and re-open your browser to expire the Kerberos ticket.
2. Sign-out will not redirect back to Sharepoint: According the WS-Federation protocol specification (http://msdn.microsoft.com/en-us/library/bb608217.aspx) appending the &wreply=encoded_URL to the query string will do the trick to redirect back to the current Sharepoint page. However with simple tests I was not able to do the trick and we need to go deeper on this.
3. Impact of the change: Replacing the entire Welcome.ascx file will need to be included as a post-configuration for the SharePoint deployment.

Reference : http://www.shailen.sukul.org/2010/05/adfs-2-sharepoint-2010-signout.html, here everything is figured out, however I will need to go deeper to tackle the identified caveats.

Para llegar a primera base y tener los conceptos básicos, les recomiendo leer un artículo que me hizo entender que habáía atrás de todo el tema de identidad y STS, es parte de la entrega 16 del Architecture Journal dedicada a identidad, el artá­culo es Claims and Identity: On-Premise and Cloud Solutions de Vittorio Bertocci. A modo de introducción también pueden rememorar la charla que dio Matias Woloski en Microsoft este año Microsoft Architecture Day: Roadmap to Identity.

Con la visión, Tokens, Claims y STSs en el bolsillo, vamos en concreto a la implementación de Microsoft que es ADFS v2 (aka Geneva Server). La mejor documentación técnica al momento se ve en el Site de ADFS v2 dentro de TechNET. Geneva Server está documentado alineado con dos casos de uso, “Web SSO Design” y “Federated Web SSO Design” si bien el segundo es el mas rico por atacar el tema de federación es importante que se entiendan ambos. Luego de comprendido el tema de Federation Server, saltamos al tema deProxy Server que utilizamos para acomodarnos a DMZs, al leer estas secciones presten especial atención al tema DNS.

Es importante manejar el tema de certificados (Sobre todo si usan publicaciones con proxy reverso de ISA Server). Hay certificados en cada Federation Server y en cada Proxy Server para garantizar autenticación segura con tokens. Finalmente, esto tiene que ver con la capa de STS exclusivamente. Recordemos que debajo de esta capa seguramente tengamos una granja NLB de Windows 2008 R2 que es un tema aparte.

Espero sea de ayuda y quisiera en futuros posts profundizar en detalles de implementación que han surjido en la práctica,

1)  In Geneva Server MMC for each Geneva Server on the farm

1. Root node
2. Edit Service Properties
3. Check “Success” and “Failure” Events

2) In Active Directory

1. Create a GPO and link to the Geneva Servers OU
2. Enable Audits
   1. Navigate to Security Settings->Local Policies->Audit Policy.
   2. Click on the  “Audit object access” Security Setting on the list view at the right side pane.
   3. On the “Local Security Setting” tab, click the “[ ] Success” and/or “[ ] Failure” check boxes according to your needs.
3. Give Permissions to the account
   1. Click Security Settings -> Local Policies -> User Rights Assignment.
   2. Double click “Generate Security Audits” and add the account of your service to Local Security Settings (you can verify service account by opening “services.msc”, and checking the “Microsoft “Geneva” Server” log on account)

Happy auditing!

I want to share the status of the Identity and Access Management (Id&AM) Portfolio offered by Microsoft with you. First begin with “What is Id&AM for the enterprise?” The following approach is the one that Oracle proposes:

My first thoughts about this scope proposed by Oracle is that they do not consider a long term Strong User Authentication strategy moving from Password Auth to SmartCard Auth.

Which is the value proposition from Microsoft? The identity portfolio has grown significantly since FY06 (when only AD and MIIS where MS players) that now we have a value proposition based on 5 Identity Management Pillars which (besides they are are product-centric) covers many of the aspects that the industry considers in the scope of Id&AM:

1) Lifecycle management: Password Sync + Certificate Mgmt + Identity provisioning

2) Information Protection: Message Encrypting + Rights Management

3) Federated Identity: Web single-sign-on. Federated Identity.

4) Strong Auth: SmartCard based auth built upon a PKI Infrastructure.

5) Directory services: Central identity repository. Authentication and role-based authorization.

As a context, Microsoft is beginning to build his identity portfolio (More focused since FY06) and now is beginning to be considered a challenger in the identity industry.

Below the Gartner magic quadrants for Web Access Management and User Provisioning.

Today Microsoft Identity Portfolio has many flaws, which you need to cover with partners solutions to gain full coverage of the Identity management needs on the Enterprise. The main flaws are regarding reporting and having a true single-sign-on framework which (again) you can only gain taking profit of partners solutions (like Quest for example)

Source:

• http://www.oracle.com/dm/07h2field/4690_cst_pri_in_a_cmptve_iam_mrktplce_us.pdf
• http://www.microsoft.com/windowsserver2003/technologies/idm/default.mspx
• http://www.sun.com/software/products/access_mgr/2h07.pdf
• http://www.sun.com/software/products/identity/2h07.pdf

See you soon!