We have requirement of build .NET based plugin/component for enabling Authentication against multiple IDP providers like ADFS, Azure AD and Shibboleth based on DB configuration. i.e, depending on the configurable parameter the anonymous user will be authenticated against any one of the IDPs like ADFS, Azure AD or Shibboleth IDP.
Our application URL ("https://www.contoso.com/ProcessToken.aspx") will be registered as RP Identifier in all of the 3 providers.
We won't make any web.config changes for any of the providers.
At run time, User will access common page(Proesstoken.aspx) who needs to get redirected to the any of the Login page URLs at the provider (ADFS, Shibboleth, Azure) for Authentication based on User Organization. (For ex: User A to ADFS, User B to Shibboleth etc)
After Successful authentication at the IDPs the user needs to get redirected by the provider (ADFS/ Shibboleth/ Azure AD) to the RP Url registered.
In the redirected page (ProcessToken.aspx), we are planning to get the security token and decipher the claims required.
The main intention is to decouple authentication away from application logic and it should be extendable to other providers in future.
PS: Considered options like OWIN Authentication Middle Tier, .NET Component etc.
Need guidance on How and where to start.
Have a look at IdentityServer 3 which implements this multi-auth scenario or OWIN : ASP.NET MVC application with multiple authentication options.
The main point is that you use NuGet to download all the protocols you require and than use OWIN to pull them all in via app.use.
You can configure ADFS to have Claims Provider Trust with the other IDP's Owin will acknowledge the authentication. The difficult part will be reading the attributes from the tokens. ADFS under the covers in conjunction with the Owin framework use ws-federation, I have not figured out how to read the SAML.
What gets confusing is that at one time the answer was WIF but now that 4.51 has been released, WIF was moved into Owin. The documentation for a multi-tenant application is sketchy at best.
Related
Is SAML an authentication mechansim. ? I have seen this being written in many places.
As per my understanding SAML is not an authentication mechanism but a way to exchange authentication and authorization data between a service provider and an identity provider. ?
Both Service provider and identity provider have to be SAML compliant or basically understand SAML to take part.
Authentication can be done by any means like oAuth, Form etc. and then SAML exchange happens.
Best Regards,
Saurav
Actually SAML is a internet standards based technology to achieve web-based single on.
The actual authentication, which happens at the SAML IdP is out of scope of the specification.
However sometimes implementors do no accurately distinguish between SSO and authentication.
Chapter 1 from SAML Technical Overview, a document published in 2008 and still a good read:
The Security Assertion Markup Language (SAML) standard defines a
framework for exchanging security information between online business
partners.
...and then Chapter 4 in the same doc
SAML consists of building-block components that, when put together,
allow a number of use cases to be supported. The components
primarily permit transfer of identity, authentication, attribute, and
authorization information between autonomous organizations that have
an established trust relationship
SAML (Security Assertion Markup Language) is an identity federation protocol.
(1) Traditionally a web application utilizes a local data storage (such as MySQL which is used to store username/password credentials) to accomplish the login authentication.
On the other hand, a web application can leverage a third-party SAML Identity Provider (IdP) to accomplish the login authentication if the web application has been integrated with a SAML Service Provider (SP).
(2) Usually a SAML IdP utilizes identity repository (such as OpenLDAP) to provide identity authentication for a SAML SP-enabled web application.
(3) A web application, which has been integrated with a SAML SP, outsources login authentication to a SAML IdP.
Without loss of generality, we assume that the SAML IdP has been configured with OpenLDAP.
A typical SAMP SP-intitiated authentication procedure can be described below.
(I) A user launches a web browser to access a SAML SP-enabled web application.
(II) The user is redirected to a SAML IdP which will prompt username/password login screen.
SAML SP sends a SAML request to SAML IdP.
(III) The user submits the username/password credential.
(IV) The SAML IdP leverages OpenLDAP to validate the username/password credential.
(V) The user is redirected back and logged in to the web application if the user has been authenticated by OpenLDAP successfully.
SAML IdP sends a SAML response token to federate the user identity (such as username) to SAML SP-enabled web application.
(4) How to build and run Shibboleth SAML IdP and SP using Docker container demonstrates how a SAML IdP utilizes OpenLDAP to provide identity authentication and then federates the user identity (such as username) to a SAML SP-enabled web application, thus accomplishing the login authentication for the web application.
I have successfully configured a SAML 2.0 Identity provider in a separate Weblogic domain
We have an ADF application deployed in Weblogic in another domain with non-SAML form-based authentication (ReadOnlySQLAuthenticator is used to verify credentials)
I want to configure the second domain as a Service Provider (to enable the existing application to login with the Identity provider.
I did the folowing:
Configure a SAML 2.0 Identity Asserter
Enable the Service Provider in the federated services for the server
Add and enable the "service provider partners" and exchange metadata on both IDP and SP side
Configure the "redirect URI" on the SP side
Add the SAML 2.0 Authenticator (the documentation doesn't mention this, but some blogs do)
This should be enough to make the SSO work, but it doesn't.
opening the application doesn't trigger a redirect to the IDP (even when the URL is configured in the provider partner config)
after logging into the application, other applications still have to log in with the IDP (SSO doesn't work)
The "other application" is the Spring SAML sample application and I verified that SSO works with 2 different instances of that app (which means the IDP side should be configured correctly).
We've had some Oracle experts come over to our company to solve various issues.
In the end even they could't help with this and suggested that SAML support may not really work that well.
They suggested that we try to use Oracle Access Manager, that's supposed to support both OAUTH and SAML. We didn't get to that yet and maybe never will.
Still if you need SSO in Weblogic, you could give it a go.
We are developing a web application that has its own SignOn mechanism (login mechanism using username and password). The SignOn mechanism is implemented using a Web Application Filter)
The web application container is Apache Tomcat 6.0
The User may also choose to login through Shibboleth authentication. That is, to access our Web Application, the user may choose either be authenticated using Shibboleth, or using our own SignOn mechanism which is web application filter-based.
Is it technically feasible to support both Shibboleth Authentication, and a Web Application Filter based SignOn mechanism?
If it's feasible, from the Web Application Filter side, how do we check if a user was authenticated already by Shibboleth? Is there some Shibboleth Authentication token, or Shibboleth User session?
Thanks.
I assume that you refer to Shibboleth SP (the Service Provider component) and also that you will need Shibboleth IdP (an Identity Provider) to provide the actual authentication.
...And yes, it is feasible and the two methods can easily coexist.
When the user is successfully authenticated by Shibboleth SP (using the Identity Provider) it place the well-known session attributes in the HTTP request attributes and headers.
You can view the session attributes visiting:
https://your-host/Shibboleth.sso/Session
So, Inside your application you can check the presence and the value of those attributes like:
request.getAttribute("NAME_OF_THE_ATTRIBUTE_IN_SESSION")
request.getHeader("NAME_OF_THE_ATTRIBUTE_IN_SESSION")
Then, using Shibboleth attributes you can do the necessary operations to allow or deny the user authentication.
See this official wiki to understand how "Shibbolize" an Application and this for accessing attributes.
I would recommend to start reading from the start this clear and comprehensive wiki on Shibboleth SP and IdP installation and configuration.
I'm trying to investigate possibility of using claims aware security in the system I'm developing. The more I read about all this stuff the more confused i get.
So i decided to describe what I know already and I would ask that You correct my statements. I got lost with all those protocols and technologies used.
Below is a simple diagram of my system. There are two services - a REST service implemented using WCF and an ASP MVC web application.
I know I need to get an STS which will be a trusted identity issuer for both of my services. I'll be using roles to differentiate certain levels of access.
The STS functionality might be accomplished by using ADFS (or is there anything more needed in addition to it) or WSO2 Identity Server.
By saying STS I mean a service which will get credentials from a client wanting to authenticate and will return a set of claims (which will beside other information contain the role assigned to the user). This set of claims will be in the form of a token.
On the diagram I marked different client types with different colors. No I'll try to describe what protocols/formats i think will be used. I am pretty confused on what is a format and what is a protocol. But let me try:
Red scenario: rich WCF client authenticates agains REST service
Request to STS will be sent using WS-trust (is there any other possibility in ADFS or WSO2?). The credentials might be in one of several forms such as X.509 certificate, password digest, kerberos, windows authentication, SAML token (this is used in federation scenarios, right?), and few other.
The answer to the client will be in a form of SWT token sent over OAuth protocol since this is the way we do it when trying to authenticate against REST services.
Does ADFS support SWT and OAuth? I couldn't find the information.
The client then send the token received from STS to the REST service. Once again this is SWT token on OAuth.
I guess as for the client code all can be easily implemented using Windows Identity Framework.
Green scenario: rich android client authenticates against REST service
All protocols/formats are the same as in previous scenario. Is there any framework which can let me easily implement this?
Blue scenario: user of web browser authenticates against ASP MVC web application
User goes to the web app's main page. The webapp detects that he isn't authenticated yet so redirects him to the sign on page on STS (the sign on page is on STS, right?).
and 3. STS authenticates the user and sends HTTP response containing SAML token and redirection to webapp. So here is HTTP used, not WS-Trusts.
Another question. In this web browser scenario there will be a cookie written on a client's machine. So whenever client will try to authenticate once again, he'll just send the cookie to sts to obtain the token. There will be no need to send the credentials. STS will issue a token basing on the cookie without any real authentication logic involved. Is that statement correct?
ADFS / WIF out the box only supports SAML tokens - no OAuth support.
ADFS / WCF uses WS-Trust.
The sign-on page is part of ADFS.
The answer is "Yes" to your last question but (at some point) it will expire and the user will have to authenticate again.
Update:
Have a look at Claims Based Identity & Access Control Guide
We are working in an iOS application and we use back-end in azure. We have 2 types of login, one is Facebook login (using Fb as identity provider) and the other will be login directly to our system.
We decided to use ACS but we had a bunch of technical problems. My question is is it possible to create custom identity provider, which will be a service (for example WCF or WEB API) to generate a token that we pass the ACS to get the claim token. Does ACS support that kind of service interface? If so what what is the practice of generating tokens in our custom identity provider?
Thanks in advance,
Deuce
ACS can support any identity provider that speaks a protocol it understands. Depending on the backend behind your identity provider, you can use something like ADFS or write your own identity provider using WIF. ACS doesn't support mixing and matching web-based identity providers with WCF-based ones, which means that you'll need to expose a website that ACS can redirect a browser to using the WS-Federation protocol. The only external contract you have is that ACS will redirect users to you and you need to log them in (what that means for your IdP is up to you) and issue a token back to ACS.
There are literally whole books on how to write your own STS using WIF, to get started there are a number of resources that can help, including the WIF SDK (which provides a template for the STS), this whitepaper (see the section "Using Windows Identity Foundation to Build a Security Token Service"), or this blog post.