I'm trying to develop an authentication plugin for an ASP.NET MVC3 application that would use WIF for authentication. Since it's a plugin with an in-system configuration, I avoid touching the web.config file of the app or anything else. I've got it working, but now I'm trying to specify what claims the STS should send my app, and it seems that FederationMetadata.xml is involved, but I cannot find confirmation of that. In fact, I cannot find any information on this enigmatic file at all. What is it?
FederationMetadata tells potential relying parties what information the STS provides.
Your claims should be detailed in the EntityDescriptor/RoleDescriptor/fed:ClaimTypesOffered section
See http://blogs.msdn.com/b/card/archive/2010/06/25/using-federation-metadata-to-establish-a-relying-party-trust-in-ad-fs-2-0.aspx
FederationMetadata is a 2 way exchange. It is used to tell the Identity Provider WHAT claims you require and the Identity Provider can use the metadata to tell your application WHAT claims it offers by default.
This way you can ensure your application has all the claims support it requires when integrating with differing identity providers.
Related
I am trying to find some information about using Apache syncope (Identity management system) with OAuth 2 authorization.
I see there is no implementation in AS yet as written here: https://issues.apache.org/jira/browse/SYNCOPE-534 so AS is "pure" Identity Manager - not directly involved in authorization operations like oauth 2.0
I have found I should use some Access Managers to implement such scenario.
What access managers should I use? Could you give some advice? thanks
On the page Access Managers you can see that there exist several ones, just not for OAuth 2.
For OAuth 2 an Access Manager had to be developed, perhaps it's possible on base of the existing ones.
Having a look at some commits concerning OpenID there exist the following list:
[SYNCOPE-1270] implementation for OpenID Connect for Admin Console and Enduser
[SYNCOPE-1270] OpenID Connect Logout implementation
[SYNCOPE-1018] self registration for OpenID Connect
It seems being mixed in core though, so probably it's impracticable to do it in the same kind as core can't be updated anymore without problems.
On the other hand, if you are willing to provide the new Access Manager directly to core-development it wouldn't matter, but then it's advisable to contact the core-developers on github first.
While REST might serve as interface for a separated module, the authentication process is technically explained as Provisioning Service.
In Extensions you get an impression which extensions exist and you'd to verify them to get knowledge how to solve your approach in an own extension. I'd chose perhaps SAML 2.0 Service Provider as it's also related to authentication.
Concerning OAuth 2 itself there exist a few implementations in github, regrettable only in PHP, but perhaps that helps you a bit.
I'am looking at the capabilities of WIF in terms of SSO. Actually we have a "legacy" users & rights management database under SQLServer and we like to build a brand new SSO system on top of this exsting database.
In many tutorials I found they talk about using existing STS like ADFSv2 for Active Directory authorization, but It did not fit my needs because my users/rights are not exposed through AD but in a custom a specific business oriented SQL Server database.
So, I thing I need a custom Security Token Service in order to be able to emit my own custom tokens, but I don't know how to do this.
I need some little help or an example about how to achieve this.
Thank you
You can find STS example in WIF SDK. It contain an example with custom token. Look here
More detail information about SSO I seen in a book 'Programming Windows Identity Foundation'
You can build your own Custom Security Token Service leveraging the underneath SQL Server database. You will have to define your scopes and Claims that needs to be shared after user does a Single Sign On. Here are some links to some articles below that has helped me build mine. I am pretty sure by following the below links you will be able to build a custom STS catering to your needs.
WIF : http://chris.59north.com/post/Building-a-simple-custom-STS-using-VS2012-ASPNET-MVC
http://www.primaryobjects.com/2013/08/08/using-single-sign-on-with-windows-identity-foundation-in-mvc-net/
Care to explain why #paullem's answer was deleted?
It is in fact the correct answer!
The question is about an STS that authenticates using a SQL DB. That is EXACTLY what IdentityServer does.
Since it's open source, you can customize it any way you want or else use it as a guide.
So to repeat the answer - "Take a look at Thinktecture.IdentityServer........".
Update
You want a custom STS that supports SAML protocol and authenticates against a SQL DB?
WIF won't do this for you.
You need to look at something like Shibboleth or simpleSAMLphp but they are not .NET based.
Or take IdentityServer and add a SAML stack to it.
Refer: SAML : SAML connectivity / toolkit.
Be warned: This is not a trivial exercise!
We've got an MVC website that is going to use DotNetOpenAuth for signing in users via OpenID and I've found this really helpful template and other more simple examples that will help me get started on that end. However, what I don't have fully figured out is how to provide my users with a way to create an account with us if they don't want to use OpenID.
I can see two options here, write some custom code that allows OpenID to piggy back on the standard membership provider. Or, have the end site only use OpenID via DotNetOpenAuth and build an Identity Provider for my users to sign up on. That way the site would only see OpenID users and wouldn't know a difference.
Are these my only options? I haven't been able to find anything on standing up my own Identity Provider, just the relying party templates. I think I can get by with just putting OpenID on top of the default membership provider, but that feels like I'm doing it wrong, since I should be able to just stand up an identity provider.
So, in my situation, what would be the best way to support membership via local account creation and OpenID via DotNetOpenAuth?
Setting up your own identity provider so that your site only speaks OAuth is certainly an option, but a non-trivial one. I wouldn't recommend setting up an identity provider unless you intend your customers to use it for logging into other sites.
Also keep in mind that most web sites don't use OAuth to authenticate (since it's not an authentication protocol anyway). OpenID is more popular.
The project template you linked to in your question demonstrates allowing users to log in via several OpenID Providers and includes support for linking user accounts.
As for supporting local user accounts as well, I suggest you take a look at the source code behind nerddinner.com. I would advise against using the ASP.NET Membership provider for the OpenID/OAuth accounts as the interface doesn't fit very well, but folks have made it work so you can too if you want.
Are there any decent examples of the following available:
Looking through the WIF SDK, there are examples of using WIF in conjunction with ASP.NET using the WSFederationAuthenticationModule (FAM) to redirect to an ASP.NET site thin skin on top of a Security Token Service (STS) that user uses to authenticate (via supplying a username and password).
If I understand WIF and claims-based access correctly, I would like my application to provide its own login screen where users provide their username and password and let this delegate to an STS for authentication, sending the login details to an endpoint via a security standard (WS-*), and expecting a SAML token to be returned. Ideally, the SessionAuthenticationModule would work as per the examples using FAM in conjunction with SessionAuthenticationModule i.e. be responsible for reconstructing the IClaimsPrincipal from the session security chunked cookie and redirecting to my application login page when the security session expires.
Is what I describe possible using FAM and SessionAuthenticationModule with appropriate web.config settings, or do I need to think about writing a HttpModule myself to handle this? Alternatively, is redirecting to a thin web site STS where users log in the de facto approach in a passive requestor scenario?
An example of WIF + MVC is available in this chapter of the "Claims Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
I do suggest reading the first couple chapters to understand all underlying principles. This blog post covers the specifics of MVC + WIF:
Link
Controlling the login experience is perfectly fine. You should just deploy your own STS (in your domain, with your look & feel, etc). Your apps would simply rely on it for AuthN (that's why a app is usually called a "relying party").
The advantage of the architecture is that authN is delegated to 1 component (the STS) and not spread out throughout many apps. But the other (huge) advantage is that you can enable more sophisticated scenarios very easily. For example you can now federate with other organization's identity providers.
Hope it helps
Eugenio
#RisingStar:
The token (containing the claims) can be optionally encrypted (otherwise they will be in clear text). That's why SSL is always recommended for interactions between the browser and the STS.
Notice that even though they are in clear text, tampering is not possible because the token is digitally signed.
That's an interesting question you've asked. I know that for whatever reason, Microsoft put out this "Windows Identity Foundation" framework without much documentation. I know this because I've been tasked with figuring out how to use it with a new project and integrating it with existing infrastructure. I've been searching the web for months looking for good information.
I've taken a somewhat different angle to solving the problem you describe.
I took an existing log-on application and integrated Microsoft's WIF plumbing into it. By that, I mean that I have an application where a user logs in. The log-on application submits the credentials supplied by the user to another server which returns the users identity (or indicates log-on failure).
Looking at some of Microsoft's examples, I see that they do the following:
Construct a SignInRequestMessage from a querystring (generated by a relying party application), construct a security token service from a custom class, and finally call FederatedSecurityTokenServiceOperations.ProcessSignInresponse with the current httpcontext.response. Unfortunately, I can't really explain it well here; you really need to look at the code samples.
Some of my code is very similar to the code sample. Where you're going to be interested in implementing a lot of your own logic is in the GetOutputClaimsIdentity. This is the function that constructs the claims-identity that describes the logged-in user.
Now, here's what I think you're really interested in knowing. This is what Microsoft doesn't tell you in their documentation, AFAIK.
Once the user logs in, they are redirected back to the relying party application. Regardless of how the log-on application works, the WIF classes will send a response to the user's browser that contains a "hidden" HTML input that contains the token signing certificate and the user's claims. (The claims will be in clear text). At the end of this response is a redirect to your relying-party website. I only know about this action because I captured it with "Fiddler"
Once back at the relying party web site, the WIF classes will handle the response (before any of your code is run). The certificate will be validated. By default, if you've set up your relying party web site with FedUtil.exe (by clicking "Add STS Reference in your relying party application from Visual Studio), Microsoft's class will verify the certificate thumbprint.
Finally, the WIF framework sets cookies in the user's browser (In my experience, the cookie names start out with "FedAuth") that contain the users claims. The cookies are not human readable.
Once that happens, you may optionally perform operations on the user's claims within the relying party website using the ClaimsAuthenticationClass. This is where your code is running again.
I know this is different from what you describe, but I have this setup working. I hope this helps!
ps. Please check out the other questions I've asked about Windows Identity Foundation.
UPDATE: To answer question in comment below:
One thing that I left out is that redirection to the STS log-on application happens by way of a redirect with a query-string containing the URL of the application the user is logging in to. This redirect happens automatically the first time a user tries to access a page that requires authentication. Alternatively, I believe that you could do the redirect manually with the WSFederationAuthentication module.
I've never tried to do this, but if you want to use a log-on page within the application itself, I believe the framework should allow you to use the following:
1) Encapsulate your STS code within a library.
2) Reference the library from your application.
3) Create a log-on page within your application. Make sure that such page does not require authentication.
4) Set the issuer property of the wsFederation element within the Microsoft.IdentityModel section of your web.config to the login page.
What you want to do is an active signin. WIF includes WSTrustChannel(Factory) which allows you to communicate directly with the STS and obtain a security token. If you want your login form to work this way, you can follow the "WSTrustChannel" sample from the WIF 4.0 SDK. Once you have obtained the token, the following code will take that token and call the WIF handler to create a session token and set the appropriate cookie:
public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}
Once you have done this, your site ought to behave the same as if passive signing had occurred.
You could use the FederatedPassiveSignIn Control.
Setting your cookie like this:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens't work for SSO to other domains.
To cookie should be set by the STS not at the RP.
Please I would like someone to tell me if dotNetOpenAuth single-sign-on.
All I want to achieve is to be able to seamlessly logging to all domains without redirect to third party system for authorisation or Authentication within a mixture programming platforms e.g (PHP or .Net)
DotNetOpenAuth library is a simple library to implement Single Sign On for .NET based application. The only issue I faced was related to performance. It was found to be a known issue with a particular API that cause the sluggishnes.
DotNetOpenAuth can be used for SSO solutions, but each new web site a user visits does need to perform a redirect to the identity provider. In a controlled SSO environment, that provider may never appear to the user, so the login is totally transparent. There are a couple of samples of an SSO configuration that comes with the DotNetOpenAuth download.
DotNetOpenAuth will help you do what you want to do provided you can support OpenID from PHP. You need to implement a provider (the site that authenticates you against a DB or other store), and a consumer (the site you want to log into).
My recommendation would be to consider the authentication protocol you wish to use rather than a specific library at first. In the case if DotNet OpenAuth it has support for:
OpenID
OAuth
InfoCard
These are just a few of the protocols available. You should also look into the SAML family of protocols, in particular SAML 2.0.
There are implementations of SAML for PHP, .NET, and many other platforms. You might want to look at a comparison between OpenID and SAML in order to choose which is better for you.