STS process

1.  install WIF 4.0
2.  install WIF SDK
3. Create test page claim aware project with .Net framework 4.0 but may need to turn to 3.5 afterwards.
4. create STS security token service project with .Net framework 4.0 but may need to turn to 3.5 afterwards.
5. “C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv” /ResetAddin Microsoft.IdentityModel.Tools.VS.VSAddin.FederationAddin (add STS reference addin)
6. create a tool(Register STS1) to register a trusted login provider, delete a trusted login provider, update trusted login provider to tie it up to a customized claim provider. Default claim provider is unable to resolve or find any unknown user id.
7. create a new sharepoint project to build a customized claim provider. 

deploy the project to sharepoint site.

 an Error may occur in deployment step
'Recycle IIS Application Pool': <nativehr>0x80070005</nativehr><nativestack></nativestack>Access denied. occurs when deploying. solution
The problem here is that Visual Studio is trying to access the site, specified in the project’s Site URL property, using the currently logged on windows account. As the site has been configured for claims-based authentication only, this process causes the access denied error to be thrown.
A quick fix for the development environment is to explicitly add your user account to the Web Application. Doing this will allow the Visual Studio process to recycle the application pool and deploy the solution package.
To do this, bring up the Central Administration site and navigate to the Manage Web Applications page (/_admin/WebApplicationList.aspx). Click on the web application that hosts the site you are trying to deploy to and then click the User Policy ribbon item.

8. Create a certificate.(optional)
    In the certificate snap-in window, in personal certificate, if the selfsigned certificate shows untrusted, copy  it to trusted folder. In snap-in, choose (right click) all tasks->manage private keys. Add read permission to machine\iis_iusrs(built in).

9. this step is easy to miss. 



10.  update people picker by running button7_Click event in the tool

You can use powershell to register a token issuer(trusted login provider) and claim provider.

run powershell
Add-PSSnapin Microsoft.SharePoint.Powershell
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\StudentFiles\STSTestCertPub.cer")
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "Email" -SameAsIncoming
$map1.AddKnownClaimValue("user1@wingtip.com")     //$map1.RemoveKnownClaimValue("user1@wingtip.com") (only if you want to remove)
$map1.AddKnownClaimValue("user2@wingtip.com")
$map1.AddKnownClaimValue("user3@wingtip.com")
$realm = "http://comutolydvs11:42412"
$signinurl = "http://localhost:5977/WingtipTST/login.aspx"
New-SPTrustedIdentityTokenIssuer -Name "STSTestCert2" -Description "STSTestCert2" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType


New–SPClaimProvider -Name "MyClaimProvider" -Type "MyClaimProvider.Providers.CustomProvider" -Scope (Get-SPWebApplication http://test)

for add a new map see http://www.blogger.com/blogger.g?blogID=6019969618846052745#editor/target=post;postID=5961657639651071813



11. some useful commands
to remove a claim provider from sharepoint, you should do
Get-SPClaimProvider -Identity "WingtipClaimProvider
Remove-SPClaimProvider -Identity "WingtipClaimProvider"

to remove features
By name

1	Get-SPFeature | Sort -Property DisplayName

By feature ID,

1	Get-SPFeature | Sort -Property Id

By feature display name alphabetically and grouped by scope,

1	Get-SPFeature | Sort -Property Scope,DisplayName | FT -GroupBy Scope DisplayName,Id

And to write this to a file to allow for viewing in Notepad, Excel etc,

1	Get-SPFeature | Sort -Property Scope,DisplayName | FT -GroupBy Scope DisplayName,Id > c:\AllInstalledFeatures.txt

List all activated site scoped features
Especially in the case of hidden features it’s sometimes necessary to track down if a feature is active on a site collection. Here’s a quick way of seeing which features are activated for an SPSite:

1	Get-SPFeature -Site http://sitecollectionurl/ | Sort DisplayName | FT DisplayName,Id

List all activated web scoped features
And only slightly modified from the Get-Help Get-SPFeature -examples text, here is a command to list all web activated featres for a site collection:

1	Get-SPSite http://sitecollectionurl/ | Get-SPWeb -Limit ALL | %{ Get-SPFeature -Web $_ } | Sort DisplayName -Unique | FT DisplayName,Id

Uninstall-SPFeature FeatureFolderName

feature is located 

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES

=============================================================================================================================================

Install claim provider 

'register dll to GAC
gacutil /i SecureAccessWAClaimProvider.dll

'install feature

xcopy SecureAccessWAClaimProvider_SecureAccessWAClaimProviderFeature "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES"
install-spfeature -path SecureAccessWAClaimProvider_SecureAccessWAClaimProviderFeature

'register the claim provider to trust login provider
$cp = Get-SPTrustedIdentityTokenIssuer "SecureAccessWA"
$cp.ClaimProviderName = "SecureAccessWAClaimProvider"
$cp.Update()

add new value

Alternativ kann man aber auch eine statische Liste bekannter Values angeben, die der Principal Picker dann anzeigt.

Hierzu muss man per PowerShell den ClaimProvider holen und die dortigen ClaimTypeInformation-Instanzen ändern, z.B. mit folgendem Script:

$cp = Get-SPTrustedIdentityTokenIssuer "ADFS_Name"


$cti = $cp.ClaimTypeInformation | ?{$_.DisplayName -eq "ClaimName"}


$cti.AddKnownClaimValue("SharePoint 2007")


$cti.AddKnownClaimValue("SharePoint 2010")


$cti.AddKnownClaimValue("SharePoint Server 2010")


//Jetzt muss nur noch definiert werden, dass ausschließlich diese Werte akzeptiert werden


$cti.AcceptOnlyKnownClaimValues = $true


//Und das Speichern nicht vergessen


$cp.Update()

 

Be aware of that you can't change any value after you register the token. 

register a STS through powershell

You will have to do this using PowerShell.  This page provides general guidance on how accomplish that, but it seems to be based on configuring federation with Geneva server.  However, I've been able to adapt this to create a custom Federated Identity Provider based on a custom STS.  I used one from the Identity Developer Training Kit as a model.  The process goes a little something like this:


1. Make sure you save the signing certificate from your STS somewhere like the c:\ drive.
2. Make sure your STS is deployed in IIS somewhere and works wiht a standard ASP.NET application. The STS examples in the training kit might be a good place to start.
3. Create a new web app. Make sure its in Claims Mode.
4. On the SP2010 server, run the following SharePoint Powershell commands:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\sts_signing.cer")
$map1 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$realm = "urn:" + $env:ComputerName + ":domain-int"
$signinurl = "https://localhost/yourcustom_sts/login.aspx"
New-SPTrustedIdentityTokenIssuer -Name "CustomSTS" -Description "Test STS" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

5. You should be able to at least add the new Federated Identity Provider by highlighting the web app and clicking the "Authentication" button in the ribbon.
6. If you left Negotiate enabled, subsequent logon attempts to that web app will result in a login page with a drop down listbox so you can pick your identity provider.

Whether this actually works, though, is an entirely different matter.  I'm having issues with it and am going write a separate post for that.

:: Travis Nielsen
:: PointBridge

Adding Claims to an Existing Token Issuer in SharePoint 2010

Clarifying the Relationship Between SharePoint 2010 and AD FS 2.0

Thursday, March 1, 2012 at 03:26PM

I was teaching an AD FS class internally here at Microsoft a few weeks ago, and during the class I covered SharePoint  2010 integration with AD FS. While there are lots of great materials out there that talk about the technical aspects of  how to set up the trust and send claims, there isn't much that really clarifies the concepts. So I just want to take a few  minutes and describe what happens conceptually, as it impacts your deployment and configuration of claims-based  SharePoint.
When a trust is established between AD FS and a typical (if there is such a thing) claims based application, the  application will accept the token from AD FS, verify it's signature, extract the claims, and use them.  A typical trust looks  something like this:

But the trust between AD FS and SharePoint, really looks something more like this:

Here, we have 2 different web apps in SharePoint, and therefore there are two different trusts from the perspective of the AD FS server. AD FS is going to create a unique token for each web app with different claims in each. However, the web apps themselves don't trust the tokens that AD FS sends to them. Instead, the SharePoint STS is what trusts the tokens that AD FS sends. Or to rephrase it another way, AD FS thinks that it is sending tokens to 2 different applications, but in reality it's not sending the tokens to either - it's sending them to the SharePoint STS.
The 3rd trust (the one that points from the SharePoint STS to the AD FS server) is the SPTrustedIdentityTokenIssuer object that you create in SharePoint. This type of design has some interesting side-effects. First, SharePoint can only have one SPTrustedIdentityTokenIssuer object for an AD FS server. Therefore, if you want different claims for each web app, you need to define the aggregate set of those claims on the SPTrustedIdentityTokenIssuer. To clarify, let's say that I want an "EmailAddress" claim in WebApp1 and an "Role" claim in WebApp2. The SPTrustedIdentityTokenIssuer object has to be configured with at least 2 claim mappings - one for "EmailAddress" and another for "Role". However, neither application is using both of them.
One of the interesting outcomes of this model is that from the application's viewpoint, there is a "pool of claims available" from the AD FS STS. Every application sees the same "pool of claims". However, if AD FS doesn't send that claim over for that particular web app, then the web app won't receive it even if it's expecting it. To visual this - imagine that I'm a user in WebApp1 and I'm defining a permission on a document library. As shown in the following image, I have 3 claims available. These are the same claims that every application sees, because it's "pool of claims" defined as "Claim Mappings" on the SPTrustedIdentityTokenIssuer object in SharePoint.

However, my Relying Party trusts in AD FS may not be configured to send all three claims for every application. So even though the end user may think that all of these claims are available for them to use, they may not be. This can be very confusing to the user - and is one of the reasons why you need to use a custom claims provider in almost every claims-based SharePoint 2010 deployment.
The FedAuth cookie box on the right of second diagam is another interesting quirk of how this trust works. In SharePoint, the STS does not send a SAML token to the web app. Instead, the STS creates the FedAuth cookie (a standard cookie used in WIF for the identity session state) which has an encrypted copy of the SessionSecurityToken object. This is the .NET object that is created by WIF after the SAML token is received, verified, and the claims are pulled out of it. So after the token is POSTed from AD FS back to the SharePoint STS, the SharePoint STS creates the FedAuth cookie and then issues a 302 redirect back to the user, which redirects the user to the original web app with their FedAuth cookie in hand. The SharePoint web app receives the cookie when the user request comes back to it and it uses WIF to extract the SessionSecurityToken object from the cookie and goes through the process of converting the identity into something that SharePoint can use internally.
So the relationship between AD FS and SharePoint is quite a bit different than other applications. If you can understand how this works, it will help you make better decisions about how to design your claims architecture in SharePoint.

Ken St. Cyr | Post a Comment | Share Article

tagged ADFS v2, SharePoint

Adding Claims to an Existing Token Issuer in SharePoint 2010

Tuesday, October 19, 2010 at 04:55PM

One of the biggest frustrations that I found when working with SharePoint and ADFS integration was that after you create the Identity Provider trust in SharePoint, you can’t add any additional claims…  or so it seems.  So after being super frustrated with this limitation, I finally just said – there’s gotta be a better way.  Turns out that there is!
Before I go through this, I want to give a shout-out to Steve Peschka’s blog post on setting up the initial trust on the SharePoint side. Steve does a great job of giving us instructions for adding the identity provider trust into SharePoint. Here’s a link to that post: http://blogs.technet.com/b/speschka/archive/2010/02/17/creating-both-an-identity-and-role-claim-for-a-sharepoint-2010-claims-auth-application.aspx.

Adding a Claim Mapping

So what do you do if you’ve already created the trust and now you want to add additional claims to it? Here’s how to do it. In this example, I’m going to add the claim http://test/shoesize to identity provider trust called sts.contoso.com. Here’s the trust before the ShoeSize claim is added:

The first thing you need to do is stick your trust into an SPTrustedLoginProvider object:
PS C:\> $ti = Get-SPTrustedIdentityTokenIssuer sts.contoso.com
Second, you will need to add the claim type to the SPTrustedLoginProvider object and update it:
PS C:\> $ti.ClaimTypes.Add(“http://test/shoesize”)
PS C:\> $ti.Update()
Now, if you look at the trust after you add the claim type, you will see it added to the list of ClaimTypes:

Next, you can create the claim mapping:
PS C:\> $map3 = New-SPClaimTypeMapping –IncomingClaimType “http://test/shoesize” –IncomingClaimTypeDisplayName “ShoeSize” –SameAsIncoming
Finally, you will need to add the claim mapping to the trust:
PS C:\> Add-SPClaimTypeMapping –Identity $map3 –TrustedIdentityTokenIssuer $ti
Now you should be able to run Get-SPTrustedIdentityTokenIssuer and see your new claim mapping.

So now we can go into SharePoint and use the claim:

Removing the Claim Mapping

OK, so you know how to add claims, but what about removing them?  The process is actually the same in reverse.
First, you need to put the trust into an SPTrustedLoginProvider object, just like you did above:
PS C:\> $ti = Get-SPTrustedIdentityTokenIssuer sts.contoso.com
Next, you will need to put the claim mapping into an object. In this example, I’m going to use the same mapping that we just added, ShoeSize:
PS C:\> foreach ($c in $ti.ClaimTypeInformation) { if ($c.DisplayName –eq “ShoeSize”) { $mapping = $c; } }
What I’m doing here is enumerating through the list of claim mappings and looking for the one whose DisplayName is “ShoeSize”. When I find it, I’m putting it into a variable called $mapping.
Next, you can run the command to Remove the mapping from the trust:
PS C:\> Remove-SPClaimTypeMapping –Identity $mapping –TrustedIdentityTokenIssuer $ti
Now, your trust should have the mapping removed, however the claim type is still there:

So as a final step, we’ll need to remove the claim type from the list:
PS C:\> $ti.ClaimTypes.Remove(“http://test/shoesize”)
PS C:\> $ti.Update()
And that’s it – your claim mapping should be gone:

Ken St. Cyr | 2 Comments | Share Article

tagged ADFS v2, SharePoint

Copyright © 2010, Ken St. Cyr. All rights reserved.

SharePoint 2010 Claims-Based Auth with ADFS v2

Rate This

Eric Kraus [MSFT]

22 Mar 2010 10:41 AM

I have a really cool 2010 lab environment at home and one of the things I wanted to do was to make sure I was able to demo SharePoint 2010 ‘s claims-based authentication capabilities, especially using ADFS v2.

I was amazed at how straight forward the process was.  Just a few lines of PowerShell and I was authenticating with our Microsoft IT’s ADFS v2 end point.  Very cool stuff.  So here’s what I did:

Pre-requisites

-First, have your security admin configure your relying point URL in ADFS v2.  This tells ADFS that you are a trusted end point and you are allowed to authenticate.  This is what allows/prevents anyone in the world from authenticating with your service (assuming they knew a correct username/password).

-Next, you will need to get the certificate used by your security team for ADFS. Save it locally.

-Lastly, you’ll need a web application that was created using “Claims-based Authentication” (not “Classic” )

Steps to configure
1.  After that is complete, Open PowerShell Management Console for SharePoint 2010 as an Administrator.

 

2.  After PowerShell opens, run the two commands below to get a reference to the certificated provided to you.

$certPath = "<path to cert>\<cert>.cer"

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("$certPath")

3.  Next, create a new trusted root authority provider within SharePoint.  Run the following command:

New-SPTrustedRootAuthority "MSIT ADFS Token Signing Trusted Root Authority" -Certificate $cert

Note: you’ll want to repeat this for each of the cert(s) in the chain, but you’ll want to end with a reference to the last cert (not the parent/root) for the rest of the process below

4.  Now, create a new claim type mapping to the claim that you will use as your identifier (e.g.  “username”).  In this case, I’ll be using the “EmailAddress” claim.

$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming

5.  Next, specify the realm (a unique URI for your site) and the sign-in URL for your site.  The realm must match what is configured for your site in ADFS.  This how ADFS knows which site to pass the claim back to.
 

$realm = "https://www.yoursite.com"
$signinurl = "https://corp.sts.yourcompany.com/adfs/ls"

6.  The last step in PowerShell creates the actually trusted identity token issuer (provider).  Run the following command using the variables you set in earlier steps:

$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFSv2" -Description "ADFSv2 Federated Identity" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl –IdentifierClaim $map1.InputClaimType

7.  Now, browse to Manage Web Applications in Central Administration (you may need to run Central Admin as an Administrator).  Click on a web application and choose Authentication Providers button in the ribbon.  And choose the appropriate zone you want to configure.

8.  Scroll down to the Claims-based Authentication Providers section and put a checkbox next to “Trusted Identity Provider”  and again next to the name of the provider you created in step #5.



Note: a great new feature in SharePoint 2010 is the ability to specify multiple authentication providers on a given zone within a web application.  e.g. you can leave Windows Authentication (NTLM) checked and also check Trusted Identity Provider.  Doing so will give you an option when you load the web application to choose which authentication method you want.




9.  The last step is to ensure all of the certificate(s) [all certs in the chain] are added to the following stores:



 
Also, confirm that your cert(s) were added to the trusted root authority (in Step 3 by viewing the certs under “Trusts” in Central Administration:





NOTE: if your certs are issued in a chain like mine were, you will also need to set the trust on your web application to Medium (via web.config) or you will receive errors like the following or create a custom trust level to include the certs.

The issuer of the token is not a trusted issuer

The root of the certificate chain is not a trusted root authority.

PowerShell, SharePoint2010, Administration, authentication, claims

Comments

• Yogesh Pawar

  16 Jun 2010 3:43 PM

  Excellent!! this is what I was looking for, time to get hold of sec admin!!
  Regards
  Yogesh Pawar

Leave a Comment

• Name
• Comment
• Post

• © 2012 Microsoft Corporation.
• Terms of Use
• Trademarks
• Privacy Statement
• Report Abuse
• 5.6.402.223

remove trusted id issuer

Agent for SharePoint Guide › Remove SiteMinder Agent for SharePoint › How to Remove the SiteMinder Agent for SharePoint › Remove the Trusted Identity Provider from any Web Applications Using it


--------------------------------------------------------------------------------

  https://supportcontent.ca.com/cadocs/0/CA%20SiteMinder%20Agent%20for%20SharePoint%202010%20r12%205-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?1838295.html


Remove the Trusted Identity Provider from any Web Applications Using it
A trusted identity provider cannot be removed from SharePoint while any web applications are using it. Before you remove the trusted identity provider itself, remove the association between the SiteMinder trusted identity provider and any of your web agents using it.

follow these steps:

1.Click Start, Microsoft SharePoint 2010 Products, SharePoint 2010 Central Administration.
The Central Administration home page opens.

2.Under Application Management, click Manage web applications.
The web application management page opens.

3.Click the line corresponding to the name of a web application using the SiteMinder trusted identity provider.
The web application is selected.

4.On the ribbon, click Authentication Providers.
The Authentication Providers dialog appears.

5.In the Authentication Providers dialog, click the link that corresponds to the zone of your web application. For example, if the web application using the SiteMinder trusted identity provider is in the Intranet zone, click the Intranet link.
The Edit Authentication page appears.

6.Under Claims Authentication types, clear all Trusted Identity provider check boxes.
7.Click Save.
The SiteMinder trusted identity provider is removed from the web application in the zone.

8.Repeat Steps 3 through 7 for all web applications and the zones using the SiteMinder trusted identity provider.
The trusted identity provider is removed from all web applications and their respective zones.


More information:

Alternate Connection Wizard Method to Help Resolve Firewall Issues



--------------------------------------------------------------------------------
Copyright © 2012 CA. All rights reserved. Tell Technical Publications how we can improve this information

quote:http://blog.sqlauthority.com/2007/08/15/sql-server-insert-data-from-one-table-to-another-table-insert-into-select-select-into-table/

SQL SERVER – Insert Data From One Table to Another Table – INSERT INTO SELECT – SELECT INTO TABLE

August 15, 2007 by pinaldave

Following three questions are many time asked on this blog.

How to insert data from one table to another table efficiently?
How to insert data from one table using where condition to anther table?
How can I stop using cursor to move data from one table to another table?

There are two different ways to implement inserting data from one table to another table. I strongly suggest to use either of the method over cursor. Performance of following two methods is far superior over cursor. I prefer to use Method 1 always as I works in all the case.

Method 1 : INSERT INTO SELECT
This method is used when table is already created in the database earlier and data is to be inserted into this table from another table. If columns listed in insert clause and select clause are same, they are are not required to list them. I always list them for readability and scalability purpose.
USE AdventureWorks
GO
----Create TestTable
CREATE TABLE TestTable (FirstName VARCHAR(100), LastName VARCHAR(100))
----INSERT INTO TestTable using SELECT
INSERT INTO TestTable (FirstName, LastName)
SELECT FirstName, LastName
FROM Person.Contact
WHERE EmailPromotion = 2
----Verify that Data in TestTable
SELECT FirstName, LastName
FROM TestTable
----Clean Up Database
DROP TABLE TestTable
GO

Method 2 : SELECT INTO
This method is used when table is not created earlier and needs to be created when data from one table is to be inserted into newly created table from another table. New table is created with same data types as selected columns.
USE AdventureWorks
GO
----Create new table and insert into table using SELECT INSERT
SELECT FirstName, LastName
INTO TestTable
FROM Person.Contact
WHERE EmailPromotion = 2
----Verify that Data in TestTable
SELECT FirstName, LastName
FROM TestTable
----Clean Up Database
DROP TABLE TestTable
GO

Both of the above method works with database temporary tables (global, local). If you want to insert multiple rows using only one insert statement refer article SQL SERVER – Insert Multiple Records Using One Insert Statement – Use of UNION ALL.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

SQL Server Downloads

generic class

last id comparison

SQL SERVER – @@IDENTITY vs SCOPE_IDENTITY() vs IDENT_CURRENT – Retrieve Last Inserted Identity of Record

March 25, 2007 by pinaldave

SELECT @@IDENTITY
It returns the last IDENTITY value produced on a connection, regardless of the table that produced the value, and regardless of the scope of the statement that produced the value.
@@IDENTITY will return the last identity value entered into a table in your current session. While @@IDENTITY is limited to the current session, it is not limited to the current scope. If you have a trigger on a table that causes an identity to be created in another table, you will get the identity that was created last, even if it was the trigger that created it.

SELECT SCOPE_IDENTITY()
It returns the last IDENTITY value produced on a connection and by a statement in the same scope, regardless of the table that produced the value.
SCOPE_IDENTITY(), like @@IDENTITY, will return the last identity value created in the current session, but it will also limit it to your current scope as well. In other words, it will return the last identity value that you explicitly created, rather than any identity that was created by a trigger or a user defined function.

SELECT IDENT_CURRENT(‘tablename’)
It returns the last IDENTITY value produced in a table, regardless of the connection that created the value, and regardless of the scope of the statement that produced the value.
IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the identity value generated for a specific table in any session and any scope.

To avoid the potential problems associated with adding a trigger later on, always use SCOPE_IDENTITY() to return the identity of the recently added row in your T SQL Statement or Stored Procedure.