I have a product which consists of internal ASP.NET/MVC web sites all using WIF to enable SSO through a custom STS/IdP service. We now have a new partner site hosted outside our network on another domain and would like to enable SSO for users as they navigate between the sites. The new site uses different technologies (e.g. python) but we assume we can create a trust relationship using SAML standards as the protocol.
With SAML as the underlying protocol we assume this can be achieved but we cannot find any guidance on patterns for implementation, best practice guidance, etc... Can some recommend some resources on how to establish this type of cross-domain trust?
Note: While other options like OAuth could address this, we would prefer to stick with a SAML-based solution
Does your custom STS/IdP service support SAML?
On the python side, they will need a SAML stack. There's a number around - refer Introduction to OneLogin's SAML Toolkits e.g. There's a good diagram there as well that shows the login flow.
Then you need to get the python SAML metadata and give them your custom STS/IdP SAML metadata.
Import on both sides, configure whatever assertions you need and you should be good to go.
You'll also need to sort out the signing certificates that go into the metadata.
Example of process using simpleSAMLPHP - Configuring the SP
Following provides excellent example of SAML implementation:
http://www.codeproject.com/Articles/56640/Performing-a-SAML-Post-with-C
We used it in our project and it worked fine.
Related
I'm setting up a personal page, and I would like to display my past work experiences and other data I have on linked-in so it is automatically updated when I update my linked-in profile. Is this possible without having to do oauth? I just want my own data.
No.
As the company says on their REST API page:
In order for your applications to access LinkedIn member data and/or act on their behalf, they must be authenticated. LinkedIn relies on the industry standard OAuth 2.0 protocol for granting access, due to its simplicity and ease of implementation.
See also this previous SO question.
This doesn't mean, however, that OAuth can't be handled for you:
As a convenience, if you are developing a front-end JavaScript or
Android application, we provide SDKs to handle the authentication
process for you.
Additionally, there are several 3rd party libraries available in the
open source community that abstract the OAuth 2.0 authentication
process for you in every major programming language.
As for the major languages they support, LinkedIn provides walkthroughs in PHP, Python, and Java on their API Get Started page.
I have built a Restful Web API for my (android) mobile application, and now i am trying to secure the access to the API. I was reading for about a week on this topic and i got the whole spectrum - from those who say that is is impossible to secure a Restful API to those who say that Https (SSL) is enough.
Here I don't want to start a discussion about that.I have settled with OAuth or OAuth2 it doesn't matter(as far as I have read OAuth seems to be the better choice, but in the Microsoft tutorials they use OAuth 2, so here i am quite confused), and yes i know that they are completely different, but I am so frustrated of searching that I would accept either (I must admit that I expceted this to be much easier). As I said, I was searching for about a week, and all I got are concepts(a lot of them). You send some data -magic start - usually username/password to the server, your data is being processed and you get a token back - magic stop-. On SO there are a lot of questions on this topic but most of the answers are unprecise (and unfortunately unusuable). For example I got this one How to secure WEB API, nice answers, but not really use of them, or this one Implement Web API with OAuth and a Single Page Application. I also got the examples from the Microsoft tutorials but there is a lot of overhead in the code and the part about OAuth isn't quite clear(which is unfortunate because the whole example should be about OAuth). I could post tons of links which claim to talk about this topic, but actually they are of no help.
What I am looking for is an simple, very very simple, example of an ASP.NET OAuth(2) implementation. It would be great if I just could use it with fiddler, provide an username/password in the header and with use of grant_type: xxx I get the token back(the permitted username/password can be hard coded inside the project, so no need for Entity framework implementation or any database on the backend). And it would also be great if someone could explain me how to use this token to authorize the user (I got it that I have to provide the Controller functions with the [Authorize] attribute, but how and where is this token-check being done ?). But please, don't post any theory about OAuth, I don't need that, here I am looking for the actual implementation of OAuth inside of Asp.Net Web Api
thanks
Here is detailed post about adding the resource owner password credentials flow for your Web API project.
The most simple implementation of OAuth2 in Web API project you can find here:
WebApiOAuth2 on GitHub
There are just two important files:
Startup.cs (with settings)
AuthorizationServerProvider.cs (authorization of users using oauth2)
I'm totally new to SAML. I want implement SSO for my ASP.NET Website. I got the SAML assertion from my client. I would like to know what are all other requirements I need to get it from my client and what setup I need to implement at my end.
Can anybody help me out in this.
Thanks in advance.
The first thing that I would do is avoid writing the SAML code yourself. There's plenty out there. #Woloski (above) has some. My company has some (I work for the company that makes PingFederate). There's some open source stuff, too. I've seen good connections from KentorIT authServices. If this is your first foray into SAML, then my bet is that ADFS is way overboard. I'll be honest, the groups we see most commonly at Ping is when they decide to go "all in" with SSO. The first one or two connections are easy. Tehn it becomes a management nightmare rapidly thereafter. The reason I say to avoid writing your own, is because there are a LOT of nuances to SAML, with massive pitfalls, and headaches you just don't need.
As the service provider (SP), you need to tell your client (Identity Provider, or IdP) what "attributes" you need from them to properly connect their users to their account in your application (maybe a username?). In addition, you can ask for additional attributes to ensure their profile is up to date - phone number, email, etc. It's up to the two of you to determine what you need (and what they'll give you). Obviously, they shouldn't send social security number, if you have no need for it.
You also need to decide if you will do SP initiated SSO (will the users get links to documents deep inside your app?), or if just IdP initiated (Or will always just come to the front door?) will suffice. What about Single Logout? Do you (or they) want to do that? [Personally, I suggest NO, but that's a different topic]
What about signing the assertion? Your cert or theirs? If you're doing SP-init, do you need to use their cert or yours for signing the AuthnRequest? Do you need encryption of the assertion, or maybe just a few of the attributes?
Generally, you do all of this with a "metadata exchange". You give them your metadata that says "this is what we need". They import that metadata to build a new connection, fulfilling the attributes your app needs with calls to their LDAP or other user repository, as well as doing authentication (if required). They finish building their connection, and export THEIR metadata, which you import to build your connection (thereby making sure you all agree on certificates). You hook it to your app, and away you go.
I make this sound easy. It is, and it isn't. Rolling your own can mean issues. Lots of them. With some being so minute that it takes pros hours (and days) to see it. When it works, it works, and well.
HTH -- Andy
you can use something like ADFS to accepto SAML Assertions. ADFS gets installed on Windows 2008 or 2012.
You would need to ask your customer
the signing certificate public key and
the sign in URL.
Then you would create a "Claims Provider Trust" in ADFS and enter those details. Then a "Relying Party Trust" that represents your application. Finally you would have to configure your application with ADFS using WIF. This blog post have more details:
http://thedotnethub.blogspot.com.ar/2012/12/adfs-20-by-example-part1-adfs-as-ip-sts.html
Also you can use Auth0 to accomplish the same without setting up any software on your side (disclaimer: I work there).
In investigating federated authentication, I've been running into a protocol alongside SAML: HTTP-FED.
Curiously, I can't find any technical documentation for this protocol.
What is it? Is it, like I suspect, a claims-based protocol for use with HTTP instead of WS- services?
HTTP-Fed appears to be a creation of a commercial vendor (Symplified). It has not been ratified by any standards bodies (that I've found) which is why you probably can't find much on it. From what I've read on their website, it appears to essentially be a fancy name for credential caching/credential replay across the internet. From their site -- http://www.symplified.com/http-federation/
"... HTTP-FED leverages the existing HTTP login mechanism at the SP.
The implication of this is that no changes to the SP (destination
application) are required and no special software is needed by SPs,
thereby reducing the effort required to federate domains."
It's not a standard so there's no info on how you'd implement it outside of buying their product. If you're looking at Web SSO for Cloud Applications, I'd stick with actual standards (SAML, OpenID, OAuth, Open ID Connect) that are designed with security in mind for this type of activity.
I need to support DoD issued CAC-based authentication in my web application deployed in JBoss. Could someone give me pointers on where to start, the steps involved, etc?
Also, which JCE provider should I go with (OpenSSO, BountyCastle, etc)? I tried to google for a list of (active/current) providers but couldn't really find it. Is there a list of JCE providers that are most popular (by virtue of their underlying security algorithms? Thanks.
I haven't worked with CAC cards, but PKI integration is typically handled by PKCS#11 middleware installed on the client CPU. On the server, you may need to intercept the request at the apache module level to enable PKI/SSO, here's a slideshow with more info on how they did it for forge.mil:
http://www.slideshare.net/rbulling/enabling-web-apps-for-dod-security-via-pkicac-enablement-forgemil-case-study
If you need to do other web based interactions with the card (non PKCS11 functions like if you want to talk to one of the other apps installed on the card from your web app, or install an applet on the card) you'll need some kind of browser plug-in to send raw APDUs or higher level commands via PCSC. My company makes a plug-in for this purpose, it's available at https://cardboss.cometway.com.
Finally, I like bouncycastle... I doubt you will find any lists of JCE providers sorted by popularity.