We have a an ASP.NET site using OWIN that stores a username\password in the DB and a client has ask if a third party system can authenticate against our data using an ADFS\SAML approach. Can we expose the data held to mimic ADFS\SAML?
Would anyone have a suggestion of how this could be possible? or even better an example of where this has been done?
Thanks
Jake
I assume you mean a 3rd party accessing your data by authenticating somewhere else and then passing a SAML token?
They would be using ADFS?
The problem is that your credentials are in a DB and ADFS requires the credentials to be in AD.
So you would have to be a SAML IDP and federate with ADFS.
This requires you to be the server side of SAML. Most libraries out there are for the client side of SAML.
So you could look at products like shibboleth, IDaaS e.g. Auth0 or commercial stacks e.g. ComponentSpace.
A diagram would be useful to clarify exactly what the use case is.
Related
I have inherited this and am stuck with this approach. I am just trying to figure out if it will in fact work.
The project involves your standard asp.net web api application with android and ios clients. The trick is with the authentication. The application is for a 3rd party, and the only way that the user can be authenticated from the outside world is by using their IDP. The 3rd party does not care what happens after the user is authenticated.
All I have to go by is the architecture diagram that the former team members created. The diagram has 3 layers. User/Mobile Device, SAML SP Web APP and Client IDP. The important part of the flow is as follows:
Mobile App calls SAML SP Web App with the IDP user name and password.
SAML Web App calls the IDP login using the user's credentials
User Authenticated ? Responds to SAML SP Web App with success and SAML Assertion/Token
SAML SP Web App responds to mobile App with approved message
Once the user is authenticated through the IDP, the plan was then to issue a bearer token to the mobile device.
Unless things have changed a lot since I last had to play with SAML (2011), it seems I am missing a client browser to redirect from the SP to the IDP and then redirect back to the SP when a valid SAMl assertion is created.
Am I missing something here, such as a way to emulate a browser to allow for these redirects and plugging in the correct user name and password, or is there a way to call the IDP directly from the SP and have it issue a response directly back to the SP? Or am I just reading the diagram wrong or inheriting some very bad assumptions? I'm in the awkward position where I don't want to go back to the client and revisit a process that was supposedly decided upon at the start of the year unless I absolutely have to.
Things don't change a lot with SAML, so your knowledge from 2011 is still definitely valid.
I'm also missing the browser redirect step. It is a quite common misunderstanding that the SP can send username/password to the Idp and get an assertion back, but that is not supported by the SAML WebSSO Profile (which is the one that's actually used).
Using SAML2 for a mobile application is hard, there's no good support in the SAML2 protocol for redirecting back to the client. A common way to work around it is to use OpenID Connect. I've been involved in setups where the mobile client authenticates to IdentityServer3 via OpenID Connect. Then IdentityServer3 acts as a SAML2 SP (through the Kentor.AuthServices middleware) to the upstream SAML2 Idp.
I understand that you are in a delicate situation but I think that you have to go back and ask how it is supposed to work. Specifically you should ask where the user is supposed to enter credentials and how the communication between the SP and Idp is supposed to work.
I'm very new to the identity management world, so please spare me. :)
What I would like to do, is to have multiple client (MVC) applications that talk to a single Web API application to authenticate their users against. In that Web API application, I would like to use ASP.NET Identity to talk to a database with users.
That way, I could use SSO for the client applications (I guess).
Does that make sense? Could someone help me on my way to implement this (links are also welcome of course)?
I don't know if IdentityServer could help me with what I want?
And as a side question: when I could implement this the way I would like to, how do I deal with the same-origin policy?
Thank you for all the help. :)
I did some research myself during the last few months and I learnt a lot about the identity management stuff. Many of that also thanks to the guys from IdentityServer (and their other projects).
What I finally did was the following (very briefly):
IdentityServer is used as a provider for all client applications. The cookie and OIDC middleware are used.
I used the ASP.NET Identity user service to store the users in an SQL Server database. (The IdentityServer configuration is by the way also stored in a database.)
I set up a Web API service that uses the ASP.NET Identity user manager for user configuration (change password, create new users, ...). It uses bearer authentication with the application with IdentityServer as provider.
As a side note, IdentityManager is used as an internal admin tool to manage all the users.
If anyone is looking for some help setting up his / her identity management system (and thinks I can help): please ask. ;)
Many articles on active profile e.g. Federated Security: How to setup and call a WCF service secured by ADFS 2.0. But that article assumes you want to use AD?
I'm guessing you want to use ASP.NET Identity for the provisioning?
IdentityServer OOTB supports a SQL DB and has basic user provisioning built in. It allows users to authenticate against the DB and supports WIF.
This scenario is also close to what you need, take a look at the answers:
How to implement an OWIN Authentication server with a MVC Web Api content server and an Android end-user apk
I also recommend reading this article:
Decouple OWIN Authorization Server from Resource Server
We have a client using SSO already with us, they post SAML assertions to one of our .aspx pages, which decodes the assertion and authenticates the user. We have been asked by a second customer to user SSO as well, but they use Active Directory Federation Services.
Having read through the documentation, I can't figure out how to use my existing solution for AD customers too, as they don't seem to send SAML assertions, but "claims", which at the moment I'm not sure what the difference between this and a SAML assertion is. Anybody could shed some light on this? If I need to write a new aspx page for my new AD customer, what would be the starting points for both ends (customer and our application)?
Claims ARE SAML assertions. The ADFS returns a SAML token including assertions (claims) and the signature.
If you already have your identity provider and you want to integrate it with ADFS, you either federate ADFS with the identity provider (so that ADFS allows users to select the authentication source) or vice versa.
I have been tasked to implement a SSO process for one our internet sites. I have been reading as much as I can to fully understand SSO and SAML so here goes:
I need to forward to a 3rd party's Service Provider (SP-3rd_party) the credentials a user used to login to our site (SP1). Then SP-3rd_party will authenticate those credentials against their own Identity Provider. Then that 3rd party IdP will redirect back to our service with either success or failure.
Our sites are all written in .NET 4.5. It seems that we as SP1 should just authenticate against their IdP and not go thru their Service Provider (SP-3rd_party). Does that make sense? I feel we are making an additional hop that shouldn't be needed but I am fairly new to all this. If anyone can provide guidance that would be great. Thank you!
This use case is commonly referred to as Service Provider Initiated SSO (SP-Init SSO) in SAML 2.0 and is fairly common. You can find a number of resources that outline the flow a little more succinctly -
http://documentation.pingidentity.com/display/PF70/SP-Initiated+SSO--Redirect-POST#SP-InitiatedSSO--Redirect-POST-1070862
https://developers.google.com/google-apps/sso/saml_reference_implementation
Also, see Section 4.1.2 of the SAML 2.0 Tech Overview document - https://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf
HTH -
Ian
We have ADFS 2.0 running and have federated with various STS.
Is it possible to federate with Windows Live, OpenID and Facebook?
Some of our users already have these types of credentials and it would be a bonus to be able to use them.
If so, what URL would be used for the federation metadata address in the "Add Claims Provider Trust" wizard?
Any other gotchas?
ADFS doesn't natively support the protocols of those IP-STSs (with the possible exception of Windows Live). You'll need to put an FP-STS that understands those protocols (e.g., PingFederate) between ADFS and them.
We have been investigating this question a lot.
It seems that the best setup is to use ACS in combination with AD FS 2.0 as described in this article.
This setup also enables claims transformation, for example, if you want to add the corporate customer number as a claim.
We have not yet seen any examples where you can connect AD FS 2.0 directly to Facebook however.
Yes . there are no direct way to get the claims from ADFS , need to configure the ACS and need to set the ACS as ID providers to ADFS.
But the token validation for ACS is 24 hours at max , so you need to be happy with short-lived token for Social Id providers.