14
Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved. A Vordel White Paper SharePoint Access Management Integrating Microsoft SharePoint To Enterprise Access Management “Applications Anywhere”

Share Point Access Management

Embed Size (px)

Citation preview

Page 1: Share Point Access Management

 

Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.

 

 

 

A Vordel White Paper  

 

SharePoint Access Management Integrating Microsoft SharePoint To Enterprise Access Management

 

 

 

 

 

 

 

 

 

“Applications Anywhere”

   

Page 2: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  2

Table of Content Table  of  Content   2  

Introduction   3  

SharePoint  Access  Management  And  Challenges   4  Front-­‐End  vs.  Back-­‐End  Single  Sign-­‐on  (SSO)   4  Integrated  Windows  Authentication   4  Limitations   4  Other  Challenges   5  

Claim  Based  Authentication   6  ADFS  As  A  Trusted  Identity  Provider   6  Federated  Claims   7  Active  vs.  Passive  Clients   8  Limitations  And  Challenges   8  

Vordel  SharePoint  Gateway   8  

Solution  Examples   9  SSO  To  SharePoint  With  Oracle  Access  Manager   9  The  Scenario   9  The  Solution   10  The  Flow   10  

Claim  Based  Access  Control  With  CA  SiteMinder   11  The  Scenario   11  The  Solution   12  The  Flow   12  

Summary   13  

Contact  Vordel   14  

About  Vordel   14  

Page 3: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  3

 

 

 

Enable  single  sign-­‐on  across  SharePoint  sites  &  applications  in  non-­‐exclusive  Microsoft  environments  

 

 

 

 

 

 

 

 

 

Introduction Microsoft  SharePoint  has  gained  wide  spread  popularity  as  a  collaboration  platform,  a  portal,  and  a  document  management  system.    SharePoint  is  easy  to  deploy,  easy  to  use,  and  integrates  seamlessly  with  other  Microsoft  products,  especially  Microsoft  Office  applications.    In  fact,  SharePoint  is  so  easy  to  deploy,  each  business  department  is  quick  to  stand  up  its  own  SharePoint  site  and  develop  SharePoint  applications  to  meet  individual  business  needs.    This  has  led  to  a  sprawling  problem  where  SharePoint  sites  and  applications  are  often  managed  locally  and  with  no  integration  to  an  enterprise  security  platform  and  standard.    This  means  SharePoint  users  often  cannot  single  sign-­‐on  (SSO)  between  SharePoint  deployments  and  other  non-­‐Microsoft  applications.    Also,  once  they  are  connected,  performance  can  be  slow,  leading  to  an  overall  poor  user  experience.  

SharePoint  relies  on  Microsoft  security  technologies  such  as  Kerberos,  NTLM,  and  Active  Directory  Federation  Server  (ADFS)  for  access  control.    Whilst  this  tight  integration  works  very  well  in  an  all-­‐Microsoft  environment,  it  makes  integration  to    non-­‐Microsoft  enterprise  access  control  and  SSO  platforms  difficult.    Most  medium  to  large  organizations  have  implemented  some  level  of  SSO  and  access  control  with  products  from  CA,  Entrust,  IBM,  Oracle,  and  RSA.    These  leading  access  management  products  offer  poor  out-­‐of-­‐the-­‐box  integration  to  the  Microsoft  technology  stack.    Enabling  SSO  across  SharePoint  applications  from  tools  like  CA  SiteMinder  or  Oracle  Access  Manager  usually  involves  a  delicate  concoction  of  agents,  caches,  and  custom  code.    Remote  and  mobile  access  to  SharePoint  is  even  more  complex  than  SSO  from  behind  the  firewall.    Enterprises  often  resort  to  point  solutions  that  are  designed  specifically  for  SharePoint  mobile  and  remote  access.      

This  white  paper  is  written  for  the  enterprise  architects  and  security  professionals  who  need  to  understand  the  challenges  of  integrating  Microsoft  SharePoint  to  enterprise  access  management  technologies.    This  white  paper  will:  

• Outline  the  basic  access  management  options  available  to  SharePoint  customers  

• Highlight  technical  challenges  involved  with  third  party-­‐integrations,  mobile  and  remote  access  to  SharePoint  

• How  to  use  the  Vordel  SharePoint  Gateway  technology  to  solve  these  problems  

For  additional  information  on  Vordel  SharePoint  Gateway  and  other  Vordel  solutions,  please  visit  www.vordel.com  for  a  wealth  of  product,  case  study,  and  best  practice  information.  

 

 

Page 4: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  4

 

 

 

Integrate  SharePoint  with  enterprise-­‐wide  access  management  platforms  from  CA,  Entrust,  IBM,  Oracle,  RSA  

 

 

 

 

 

 

 

 

 

SharePoint Access Management And Challenges  

Front-End vs. Back-End Single Sign-on (SSO)

There  are  two  aspects  to  SharePoint  SSO.    There  is  the  SSO  into  SharePoint  from  enterprise  SSO  solutions  such  as  CA  SiteMinder  and  Oracle  Access  Manager.    This  is  the  subject  we  will  cover  in  this  white  paper.    The  ability  for  SharePoint  to  single  sign-­‐on  to  backend  business  systems  such  as  SAP,  Siebel,  and  BizTalk  Server  to  retrieve  data  is  a  separate  topic  that  will  not  be  covered  in  this  white  paper.    There  are  abundant  resources  you  can  find  on  the  back-­‐end  SSO  topic  by  searching  on  keywords  such  as  “SharePoint  SSO  Service”  or  “SSOSrv”.    Vordel  SharePoint  Gateway  can  also  simplify  your  backend  SSO  integrations.    Please  contact  Vordel  for  more  details.  

 

Integrated Windows Authentication

Both  SharePoint  2007  and  2010  rely  on  Integrated  Windows  Authentication  service,  which  consists  of  Kerberos  v5  and  NTLM  authentication. Kerberos  v5  authentication  is  the  default  when  Active  Directory  is  installed  on  a  domain  controller  running  Windows  2000  Server  or  Windows  Server  2003,  and  the  client  browser  supports  the  Kerberos  v5  protocol.    NTLM  authentication  is  used  otherwise.    Integrated  Windows  Authentication  also  supports  the  Negotiate  authentication  method,  also  known  as  SPNEGO,  a  wrapper  for  Kerberos  v5  and  NTLM.    Negotiate  allows  a  way  for  the  client  application  to  select  the  best  security  provider  for  the  situation.    You  can  learn  more  about  Integrated  Windows  Authentication  at  http://technet.microsoft.com/en-­‐us/library/cc758557(v=WS.10).aspx  

This  tight  integration  works  well  in  a  homogenous  Microsoft  environment  because  Microsoft  has  done  a  great  job  of  hiding  all  the  complexity  underneath.    In  the  simplest  scenario,  if  a  user  is  logged  on  to  a  Windows  computer  that  is  part  of  a  Windows  domain  that  the  SharePoint  is  also  a  member  of,  Integrated  Windows  Authentication  will  automatically  log  the  user  into  SharePoint  without  prompting  for  a  user  name  and  password.    

Limitations  

However,  Kerberos  v5  and  NTLM  have  the  following  known  limitations:  

• NTLM  is  connection-­‐based,  thus  it  cannot  reliably  work  through  a  firewall.    Proxies  do  not  reliably  maintain  connections.  

• Kerberos  v5  requires  the  client  to  have  a  direct  connection  to  Active  Directory.    This  is  not  the  case  for  most  external  /  Internet  /  Cloud  /  Mobile  integration  scenarios.  

Page 5: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  5

 

 

   

Enable  remote  &  mobile  access  to  SharePoint  from  any  device,  anywhere  

 

 

 

 

 

 

 

 

 

 

• Kerberos  v5  requires  that  both  the  client  and  the  server  have  a  trusted  connection  to  a  Key  Distribution  Center  (KDC)  and  be  compatible  with  Active  Directory.    In  a  heterogeneous  environment    involving  non-­‐Microsoft  technologies,  an  intermediary  is  often  required  to  broker  the  connections.  

• Before  a  service  can  use  Kerberos,  it  must  be  registered  with  a  service  principal  name  (SPN)  in  Active  Directory.    This  registration  process  is  manual  unless  the  service  name  happens  to  be  the  same  as  NetBIOS  or  computer  name.  

• Kerberos  authentication  requires  a  service  to  be  registered  with  only  one  account  object.    Thus,  only  one  application  pool  that  has  the  service  registered  can  authenticate  using  Kerberos.    So  if  a  website  has  more  than  one  application  pool,  Kerberos  will  require  all  application  pool  processes  to  have  the  same  identifier.  

• A  Kerberos  ticket  only  includes  a  user’s  account  and  a  list  of  AD  Groups  the  user  belongs  to.    It  does  not  include  other  useful  attributes  such  as  email  address  and  client  type  that  maybe  required  for  further  contextual  authentication  and  fine-­‐grained  authorization.    Extending  a  Kerberos  ticket’s  attributes  requires  custom  programming  of  Active  Directory.  

Other  Challenges  

Without  careful  setup  of  Kerberos  authentication,  these  common  deployment  scenarios  will  cause  Kerberos  authentication  to  fail:  

• If  the  Fully  Qualified  Domain  Name  (FQDN)  is  not  the  same  as  the  NetBIOS  name,  Kerberos  authentication  will  fail.    For  example,  the  IIS  server  hosting  the  www.vordel.com  website  is  hosted  on  a  server  named  www01.  

• The  authentication  process  runs  under  a  non-­‐System  identity  and  no  SPN  is  registered  for  that  identity  

• Applications  are  hosted  across  multiple  servers  that  use  the  same  computer  name  

• All  servers  in  a  web  farm  use  one  computer  name  and  one  SPN.    Load  balancers  distribute  requests  to  multiple  servers.  

Because  of  these  limitations,  Integrated  Windows  Authentication  is  really  only  suitable  for  intranet  deployment  scenarios  and  most  suitable  for  homogeneous  Microsoft  environments.    It  is  not  suitable  if  any  of  the  following  applies  to  your  situation:  

• Connection  goes  through  a  HTTP  proxy,  but  NTLM  is  being  used  • Application  users  do  not  have  accounts  in  your  Windows  domain  • Multiple  Windows  forests  that  do  not  have  mutual  trust  relationships  • Integration  with  Java  or  other  non-­‐.NET  Framework  applications  • Support  for  non-­‐Windows  platform  such  as  Mac  OS  and  Linux  

Page 6: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  6

 

 

 

Enable  claim-­‐based  User  Policies  in  SharePoint  to  reduce  user  account  administration  overhead  

 

 

 

 

 

 

 

 

 

Claim Based Authentication

SharePoint  2010  introduces  an  additional  claim-­‐based  authentication  model  to  address  some  of  the  deficiencies  associated  with  Integrated  Windows  Authentication.    You  can  find  the  background  on  this  new  feature  and  the  general  topic  of  claim-­‐based  authentication  at  the  following  Microsoft  site:  http://msdn.microsoft.com/en-­‐us/library/ff423674.aspx.    As  with  most  Microsoft  solutions,  this  Microsoft  article  is  written  for  a  Microsoft  only  environment,  utilizing  .NET  Framework,  ASP.NET,  Windows  Communication  Foundation  (WCF),  Microsoft  Active  Directory,  and  Microsoft  Visual  C#.  

In  a  nutshell,  claim-­‐based  authentication  requires  the  SharePoint  Server  to  grant  access  based  on  the  claims  issued  by  a  trusted  identity  provider  (TIP).    The  claim  can  include  user  identifier  such  as  Windows  username,  email  address,  or  third-­‐party  SSO  ID.    The  claim  can  also  include  roles  and  attribute  claims  that  SharePoint  can  use  to  determine  the  appropriate  access  level.    The  authentication  of  the  user’s  identity  is  delegated  to  the  TIP.    SharePoint  relies  on  the  claims  asserted  by  the  TIP  via  an  explicit  trust  relationship  preconfigured  using  the  WS-­‐Trust  or  WS-­‐Federation  protocols.    With  a  claim-­‐based  model,  a  SharePoint  server  no  longer  needs  to  have  knowledge  of  user  accounts.      Users  can  be  anonymous  to  SharePoint.    User  Policies  in  SharePoint  can  simply  be  role  or  attribute  based,  greatly  simplifying  the  administration  overhead  when  compared  to  managing  individual  user  accounts.  

ADFS  As  A  Trusted  Identity  Provider  

In  a  Microsoft  environment,  with  Windows  Server  2008  R2  Enterprise  Edition,  Active  Directory  Federation  Services  (ADFS)  2.0  can  be  configured  as  a  TIP  to  issue  claims.    ADFS  provides  a  number  of  options  to  authenticate  users,  including  Kerberos,  forms  authentication,  or  certificates.    SharePoint  can  support  multiple  authentication  schemes,  so  one  can  potentially  set  up  both  Integrated  Windows  Authentication  and  a  claimed-­‐based  scheme  for  different  user  populations  or  different  access  channels.    Custom  coding  is  required  to  ensure  consistency  of  the  claims  generated  by  the  different  TIPs  and  provide  the  proper  user  interface  to  let  users  select  an  identity  provider  at  login.    Follow  this  link  to  learn  more  about  setting  up  ADFS  as  a  TIP  for  SharePoint:  http://msdn.microsoft.com/en-­‐us/library/hh446525.aspx.    For  detailed  step-­‐by-­‐step  instructions  on  how  to  setup  a  TIP  for  SharePoint  and  other  interesting  SharePoint  topics,  check  out  this  very  informative  blog  at  Share-­‐n-­‐dipity  blog  (http://blogs.technet.com/b/speschka/.  

 

Page 7: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  7

 

 

 

Avoid  fragile  custom  solutions  &  invasive  agent-­‐based  solutions  that  are  costly  to  deploy  &  manage    

 

 

 

 

 

 

 

 

 

 Figure  1:  Claim-­‐Based  Authentication  Using  ADFS  (Diagram  Source:  

http://msdn.microsoft.com/en-­‐us/library/ff359108.aspx)  

Federated  Claims  

In  a  federated  setup,  ADFS  can  also  accept  a  security  token  such  as  a  Security  Assertion  Markup  Language  (SAML)  2.0  token  from  another  identity  provider  as  proof  of  authentication.    The  identity  provider  /  claim  issuer  can  be  another  ADFS  instance;  a  non-­‐Microsoft  federation  server;  a  security  token  service,  or  a  Cloud  based  federation  broker.  

 

 

Page 8: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  8

 

 

 

Integrate  SharePoint  to  enterprise  security  framework  &  improve  governance  for  SharePoint  deployments  

 

 

 

 

 

 

 

 

 

Active  vs.  Passive  Clients  

The  claim-­‐based  model  can  involve  active  or  passive  clients.    An  active  client  can  handle  more  sophisticated  authentication  and  token  management  scenarios.    Active  client  in  the  Microsoft  world  can  leverage  the  Windows  Communication  Foundation  (WCF)  library  to  handle  these  tasks  using  the  WS-­‐Trust  protocol.    In  contrast,  a  passive  client  uses  a  much  simpler  protocol  to  request  and  pass  around  tokens  that  rely  on  HTTP  primitives  such  as  HTTP  GET  and  POST.    The  passive-­‐client  model  is  supported  by  a  much  broader  range  of  clients,  including  most  web  browsers.    In  the  Microsoft  world,  the  simpler  WS-­‐Federation  protocol  is  used  for  this  model  instead  of  WS-­‐Trust.  

Limitations  And  Challenges  

The  challenges  associated  with  using  a  claim-­‐based  model  with  SharePoint  once  again  centers  around  integration  with  third-­‐party  technologies  in  a  heterogeneous  environment,  especially  when  other  proprietary  and  legacy  technologies  are  involved.    Some  of  the  challenges  include:  

• Configuring  non-­‐Microsoft  access  management  products  as  TIPs  • Interoperate  with  common  proprietary  tokens  such  as  ObSSO  cookie  from  

Oracle  Access  Manager  or  CA  SiteMinder  session  token  • Deploy  and  manage  additional  agents  from  access  management  products  • Mediate  claim  format  from  multiple  TIPs  • Deploy  mixed  claim-­‐based  and  non-­‐claim-­‐based  authentication  schemes  • Deploy  advanced  access  control  polices  based  on  network,  client,  time-­‐of-­‐day  

and  other  contexts  • Token  caching  to  minimize  token  generation  and  re-­‐authentication  requests.  • Manage  WS-­‐Trust  and  WS-­‐Federation  relationships  • Manage  certificates  and  integrate  with  Certificate  Authorities  • Reconcile  the  Microsoft  claimed-­‐based  model  with  other  fine-­‐grained  

authorization  technologies  for  Axiomatics,  Oracle  and  Quest  

 

Vordel SharePoint Gateway

Vordel  SharePoint  Gateway  provides  out-­‐of-­‐the-­‐box  integrations  between  SharePoint  and  all  leading  identity  and  access  management  products,  including  CA,  Entrust,  IBM,  Oracle,  Quest,  and  RSA.    Vordel  offers  an  agent-­‐less,  non-­‐invasive  solution  that  is  simpler  and  more  reliable  than  the  agent-­‐based  solutions  offered  by  access  management  vendors.    Vordel  SharePoint  Gateway  may  be  the  right  solution  for  you  if  any  of  the  following  scenarios  apply  to  your  SharePoint  deployment:  

• Have  deployed  SSO  solution  from  a  non-­‐Microsoft  vendor  • Have  multiple  SSO  solutions  across  different  domains  and  business  units  • Have  embedded  SSO  solutions  in  ERP  (e.g.  Oracle  and  SAP)  and  other  business  

applications  

Page 9: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  9

   

 

 

Maintain  SharePoint  integration  &  update  policies  with  easy-­‐to-­‐use  drag-­‐and-­‐drop  configuration  user  interface  

 

 

 

 

 

 

 

 

 

• Using  both  on-­‐premise  and  Cloud-­‐based  SSO  solutions  • Need  to  deployed  mixed  mode  authentication  schemes  • Need  to  integrate  strong  authentication  solutions  • Prefer  not  to  use  an  agent-­‐based  solution  • Prefer  not  to  build  and  maintain  custom  integration  code  • Are  migrating  or  plan  to  change  SSO  product  

 Figure  2:  Drag-­‐and-­‐Drop  Configuration  

Please  see  Vordel.com  for  more  information  on  the  Vordel  SharePoint  Gateway  and  other  solutions.  

 

Solution Examples

Every  SharePoint  deployment  is  unique  so  every  SharePoint  SSO  problem  is  a  little  bit  different.    Vordel  SharePoint  Gateway  offers  drag-­‐and-­‐drop  configuration  to  accommodate  the  most  demanding  SharePoint  integration  requirements.    We  will  examine  how  the  Vordel  solution  works  using  representative  deployment  scenarios  from  actual  Vordel  customers.  

 

SSO To SharePoint With Oracle Access Manager

The  Scenario  

The  company  BigPharma  has  standardized  on  Oracle  Access  Management  Suite  as  the  enterprise  wide  access  control  and  SSO  solution.    Oracle  Access  Manager  (OAM)  is  used  to  protect  nearly  all  web  applications  within  the  organization  across  the  globe.      

Page 10: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  10

 

 

 

Accelerate  SharePoint  performance  by  at  least  30%  &  improve  user  experience  

 

 

 

 

 

 

 

 

 

 

BigPharma’s  identity  management  roadmap  calls  for  future  rollout  of  Oracle  Entitlements  Server  and  Oracle  Adaptive  Access  Manager  for  fine-­‐grained  authorization  and  contextual  authentication.    There  are  over  30  SharePoint  sites  and  applications  that  BigPharma  wishes  to  enable  SSO  through  OAM.    BigPharma  has  decided  deploying  Oracle’s  IIS  based  integration  on  each  SharePoint  server  is  not  a  desirable  option  and  wishes  to  deploy  a  more  scalable  and  manageable  solution  using  the  Vordel  SharePoint  Gateway.  

The  Solution  

In  this  implementation  the  Vordel  SharePoint  Gateway  is  deployed  as  a  proxy  for  all  SharePoint  traffic.    All  SharePoint  requests  from  the  browsers  are  routed  to  the  Gateway  for  the  purpose  of  security  integration  as  well  as  performance  acceleration.    Vordel’s  OAM  Connector  is  used  to  authenticate  the  user  against  OAM.    Vordel’s  Kerberos  Connector  is  used  to  acquire  Kerberos  service  tickets  on  behalf  of  the  end  user  to  access  SharePoint.    Throughout  this  entire  integration,  the  Gateway  has  no  knowledge  of  the  end  user’s  Kerberos  password.  

 Figure  3:  Single  Sign-­‐on  Using  Third-­‐Party  Access  Management  Product  

By  routing  all  SharePoint  requests  through  the  Gateway,  BigPharma  has  improved  SharePoint  performance  by  a  minimum  of  30%.    Performance  acceleration  is  not  in  the  scope  of  this  security  white  paper.    To  learn  how  the  Gateway  can  accelerate  SharePoint  performance  using  intelligent  cache  management,  contact  a  Vordel  product  expert.    

 

 

 

Page 11: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  11

 

 

   

Expose  SharePoint  data  &  features  externally  with  strong  access  control  &  threat  protection  

 

 

 

 

 

 

 

 

 

 

The  Flow  

1. The  user  John  enters  a  SharePoint  URL  in  his  browser  and  the  request  hits  the  Gateway.    The  Gateway  instructs  the  browser  to  send  OAM’s  ObSSO  cookie.  

2. The  Gateway  receives  the  ObSSO  cookie  and  validates  the  token  with  OAM.  

3. The  Gateway  maps  John’s  OAM  username  to  a  Kerberos  User  Principal  Name  (UPN).  

4. The  Gateway  queries  its  Kerberos  token  cache  to  determine  if  a  service  ticket  already  exists  for  John’s  UPN  and  the  SharePoint  Service  Principal  Name  (SPN).    If  a  ticket  is  found  in  the  cache,  the  Gateway  further  checks  the  ticket  for  expiration.    If  there  is  no  cached  service  ticket  or  if  the  cached  ticket  has  expired,  the  Gateway  invokes  the  Impersonation  Token  Service  passing  the  UPN  and  SPN.  

5. The  Impersonation  Token  Service  first  acquires  a  Kerberos  service  ticket  for  the  UPN  to  access  itself  via  the  Kerberos  S4U2Self  extension.    It  then  uses  the  Kerberos  S4U2Proxy  extension  to  acquire  a  Kerberos  service  ticket  for  the  UPN  to  access  the  SPN.    The  Impersonation  Token  Service  acquires  these  tickets  by  invoking  the  Kerberos  KDC  /  Windows  Domain  Controller  

6. The  Impersonation  Token  Service  returns  the  token  to  the  Gateway.    The  Gateway  extracts  the  service  ticket  and  client-­‐service  session  key  for  John  to  access  SharePoint.    The  service  ticket  and  session  key  are  cached  in  the  Gateway.  

7. The  Gateway  generates  the  Kerberos  SPNEGO  token  which  contains  the  unique  authenticator  data  and  the  service  ticket  for  SharePoint.    The  Gateway  inserts  the  SPNEGO  token  into  the  authorization  header  of  the  request  to  SharePoint.  

8. SharePoint  authenticates  John  using  the  SPNEGO  token,  performs  the  requested  operation,  and  returns  the  response  to  the  Gateway.    The  Gateway  then  passes  the  response  back  to  the  browser.  

Claim Based Access Control With CA SiteMinder

The  Scenario  

The  company  InsuranceCo  plans  to  upgrade  all  its  SharePoint  sites  to  SharePoint  2010.    As  part  of  this  upgrade  project,  InsuranceCo  would  like  to  enable  SSO  to  SharePoint  via  CA  SiteMinder  and  switch  to  the  more  scalable  claim-­‐based  authentication  and  authorization  scheme.    CA  SiteMinder  is  the  enterprise  wide  access  control  and  SSO  platform.    InsuranceCo  asked  its  existing  XML  gateway  appliance  vendor  to  help  with  this  SharePoint  integration.    After  one  year  of  trying,  InsuranceCo  concluded  that  its  current  XML  gateway  is  not  capable  of  handling  SharePoint  integration  without  an  extensive  amount  of  custom  code.    Another  gateway  vendor  declined  to  compete  after  reviewing  the  use  cases.    InsuranceCo  selected  Vordel  SharePoint  Gateway  for  an  out-­‐

Page 12: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  12

 

 

 

Monitor,  track,  audit,  &  report  SharePoint  access  &  transactions  

 

 

 

 

 

 

 

 

 

 

 

of-­‐the-­‐box  solution  that  demonstrated  all  of  the  company’s  use  cases  within  one  week.  

The  Solution  

In  one  aspect  of  this  implementation  the  Vordel  SharePoint  Gateway  is  deployed  as  a  trusted  identity  provider  (TIP)  to  SharePoint.    SharePoint  authentication  requests  are  delegated  to  the  Gateway.    Vordel’s  CA  SiteMinder  Connector  is  used  to  authenticate  the  user  against  SiteMinder  and  retrieve  additional  user  attributes.    The  Gateway  generates  a  WS-­‐Trust  RSTR  (Request  Security  Token  Response)  with  a  SAML  token.    User  attributes  are  inserted  as  SAML  attributes.    SharePoint  uses  these  user  attributes  to  make  access  control  decisions,  without  any  explicit  knowledge  about  the  user  identity.    All  the  SharePoint  administrators  need  to  manage  are  role  based  User  Policies  within  SharePoint.    The  Gateway  also  uses  the  Kerberos  credential  to  obtain  a  SiteMinder  token  for  further  SSO  to  other  applications.  

 Figure  4:  Claim-­‐Based  Access  Control  Leveraging  Third-­‐Party  Access  Management  Products  

The  Flow  

• The  user  Alex  is  logged  into  his  Windows  PC  and  domain  via  username  and  password.    Alex  enters  a  SharePoint  site  URL  in  his  browser  and  the  request  hits  the  Gateway.    The  Gateway  instructs  the  browser  to  send  a  Kerberos  SPNEGO  token.  

• The  browser  obtains  a  Kerberos  ticket  for  the  Gateway  from  the  domain  controller. This  token  is  sent  to  the  Gateway  in  the  HTTP  headers  as  a  SPNEGO  token.    Alex  is  not  prompted  to  enter  his  credential  into  the  browser.  

• The  Gateway  maps  Alex’s  Kerberos  UPN  to  a  SiteMinder  username,  authenticates  Alex  with  SiteMinder,  obtains  additional  user  attributes,  and  requests  a  SiteMinder  session  token.    The  Gateway  can  obtain  a  SiteMinder  session  token  without  knowledge  of  Alex’s  SiteMinder  password.  

Page 13: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  13

 

 

   

Deploy  a  SharePoint  access  management  solution  that  has  great  flexibility,  scalability,  &performance  

• The  Gateway  packages  Alex’s  email  address  and  a  number  of  attributes  into  a  SAML  token,  then  sends  the  SAML  token  to  SharePoint  using  WS-­‐Trust  RSTR  protocol.  

• SharePoint  uses  the  user  attributes  in  the  SAML  token  to  determine  access  rights  using  claim-­‐based  User  Policies  defined  in  SharePoint.    Alex’s  attributes  give  him  limited  read-­‐only  access  for  this  SharePoint  application.    Alternatively  another  user  Mary’s  attributes  can  give  her  editing  rights.  

• When  Alex  attempts  to  access  other  SiteMinder  protected  applications,  the  Gateway  can  use  the  SiteMinder  session  token  to  SSO  Alex  into  those  applications.  

 

Summary

Microsoft  SharePoint  is  easy  to  deploy  and  easy  to  use,  until  you  have  to  integrate  it  with  enterprise  access  management  and  SSO  platforms.    SharePoint’s  reliance  on  Microsoft  security  foundation  technologies  makes  integration  to  third-­‐party  security  platforms  extremely  complex  and  challenging.    Instead  of  cooking  up  a  concoction  of  custom  integration  code  and  deploying  intrusive  agents  into  every  SharePoint  instance,  Vordel  SharePoint  Gateway  offers  an  alternative  that  is  agent-­‐less,  non-­‐invasive,  easy  to  deploy,  easy  to  manage,  and  ready  to  scale.    The  Gateway  takes  care  of  all  the  complicated  orchestrations  between  Microsoft  and  other  vendors’  security  products  to  deliver  a  seamless  experience  for  the  end  users  and  a  painless  experience  for  SharePoint  administrators.  

 

Page 14: Share Point Access Management

 

SHAREPOINT  ACCESS  MANAGEMENT  

   

“Applications Anywhere” Copyright © 2012, Vordel Inc. and/or its affiliates. All rights reserved.     Page  14

Contact Vordel For  more  information  or  sales  enquiries,  contact  [email protected]  USA  +1  866-­‐460-­‐0987  |  EMEA  +44  203-­‐427-­‐5082  |  APAC  +61  28  014  4591  

           Follow  us  on:  

                                             www.twitter.com/vordel          

                                                                 http://www.linkedin.com/groups/Vordel-­‐Community-­‐3745749?  

About Vordel Vordel  delivers  fast,  safe,  connectivity  for  SOA  and  Cloud  Services.  Vordel  Application  Gateway  provides  integration,  security,  governance,  and  acceleration  for  enterprise  applications  and  Cloud  based  services.  Vordel  Application  Gateway  enables  Fortune  5000  enterprises  and  government  agencies  to  extend  their  enterprise  applications  and  SOA  infrastructure  beyond  the  perimeter  to  enable  Cloud  based  services  and  mobile  computing.  Vordel  makes  it  possible  to  deliver  and  consume  “Applications  Anywhere”  with  IT’s  existing  applications  and  infrastructure,  without  costly  upgrades  and  rewrites.