Configuration is: ADFS 2.0 as IdP (both WS-Federation and SAML 2.0 are supported), ASP.NET app as Service Provider. When SPS requests ADFS with WS-Federation standard (WIF used) it lets me login to ADFS automatically with no login pop-up window even if new session started, so that Kerberos token does its job well as expected. However in case of SAML 2.0 (ComponentSpace.SAML.2 lib is used) every time I open IE9 and being redirected to ADFS, I'm asked to enter my windows domain credentials in a standard small pop-up login window. Is any SAML 2.0 parameter or other technique letting me to get rid of this window like in the WS-Fed case? Thanks
adfsserver.us.mycompanyname.com/adfs/ls is in the Internet zone and the automatic login will not happen.
adfsserver/adfs/ls is in your Intranet zone in IE and will log in automatically.
You could add adfsserver.us.mycompanyname.com to your trusted (or Intranet zone) sites list and you should be not be prompted for credentials.
It's not an answer, it's rather update to my question, but it's important and I decided to put it as an answer to attract more attention to it. What I've figured out playing with the SAML parameters for few days is that it seems to be not depend on protocol (WS-Federation/SAML2). What it actually depends on is long/short adfs server domain name, so that authentication request like https://adfsserver.us.mycompanyname.com/adfs/ls makes this window appear, while https://adfsserver/adfs/ls does not. However I can not use short domain name for SAML 2.0, I'm getting error in the case: "MSIS1006: The configured passive endpoint 'https://adfsserver.us.mycompanyname.com/adfs/ls/' is not a prefix of the incoming SAML message Destination URI 'https://adfsserver/adfs/ls/'". BTW, we use SSO in our local intranet only, so I do not know why this exception occures. Any workaround?
You can change passive endpoint server following steps mentioned below:
http://breakingdevelopment.blogspot.in/2012/12/adfs-msis1006-i-am-working-on-sso.html
Open ADFS 2.0 Service Manager
Select "Edit Federation Service Properties..." from the top right corner. This brings up the Federation Service Properties window
Change the Federation Service Identifier to match the Identity Provider URL (IdPURL) passed from your SSO application.
Try: urn:federation:authentication:windows instead of: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
in this part of the SAML 2.0 authentication request:
<saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</saml:AuthnContextClassRef>
Related
We've got a web application running in a WebSphere App Server 8.5.5 environment that we're currently authenticating against a database table. We're now changing things to authenticate with SAML against an ADFS IdP. Here's the rub: some users might not exist in the ADFS (the AD behind the ADFS). So the scenario I believe we want is either:
1) If we receive a SAML response with failed authentication, fallback to form-based authentication
or
2) Somehow have 2 entry points into the application, 1 SAML-driven and the other starts with form-based login.
Has anyone come up against this same scenario, and are either of the above possible solutions workable in WebSphere 8.5.5?
In WebSphere SAML service provider (SP) implementation, upon detecting received SAMLResponse is in valid, SP redirects user to a pre-configured login page (start a new SSO), or an error page. Doing this can sure user is always authenticated by SAML IdP, and authenticated subject always contains SAML for propagation and other post processing.
SAML SP supports filter, and only accept requests that satisfy conditions defined in filter. You can define filter condition that should be ignored by SAML, and you can use URL pattern, or any http header name as filtering condition.
If filter can not meet your requirement, we could further evaluate other options.
Premise:
I have an infrastructure where we have a custom RP-STS implemented with Windows Identity Foundation, providing SSO for a few websites. This STS communicates with the sites via WSFederation. This custom STS is about to be deprecated because the organization is adding an Open ID Connect Idp into the infrastructure.
The websites themselves (Episerver) contain all the custom made authorization logic already based on the claims the STS provides, and if we were to simply toss the STS we'd have to replace all of this logic.
Question:
What is the browser redirect flow to integrate our RP-STS to the openId connect provider in such a way that the end user browser gets a session for both our RP STS and the Open Id Connect IdP?
Personal thinking on how it might be doable (based on massive assumptions on how openid connect works), skip this if you know how to answer:
Website sends HTTP post to RP-STS containing username/password
RP STS responds to browser with redirect to OpenId Connect Idp (Redirect contains username / password, and a replyto address is set to the RP STS)
OpenId Connect Idp creates a local session (???) and responds with a redirect to RP STS, redirect contains auth_token. (I'm unsure of the parts that go into an openid connect login flow)
RP STS receives user token and gets / asks for user data, builds claims and builds local session
RP STS sends claims in SAML token via WSFed to RP site
Am I even close?
Further clarification:
I do not want to remove the existing STS, but abstract the new infrastructure change behind it so that from the end-user-sites perspective, identity objects and authorization logic will remain unchanged.
I need help specifically in seeing if the login/logout flow is doable between the STS and the Open ID Connect IDP
WIF and OpenID Connect are completely different protocols e.g. WIF is mainly browser based in the passive profile. The token types are different - SAML and JWT etc.
The way to do this is via OWIN (Katana is the Microsoft implementation). There are NuGet packages for both WS-Fed and OpenID Connect.
There are samples available for Azure AD - refer Microsoft Azure Active Directory Samples and Documentation that you could use as a guide.
OWIN would allow you to use both protocols.
In fact, have a look at IdentityServer3.
This is an open source STS implementation of both.
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.
I've a question about oauth2 and its suitability in this case. I've looked at the authorization flow, but that always seems to start the process from the 3rd party web app, not from the portal (auth server)...
My terminology...
1) We have Enterprise Portal system (e.g. SharePoint etc), let's call it portal.com
2) We have a 3rd party hosted web app, let's call it webapp.com
A user, already logged in (authenticated) in portal.com clicks a link on one of the portal pages that opens up webapp.com (my 3rd party, cross domain web app). I want to authorize the user to use webapp.com without the need for supplying any extra login credentials.
Questions:
a) is oauth2 the most common 'standards' based way to do this? Or have I misunderstood something.
b) If it is, what is the authorization flow? (I only seem to find auth flows that start from the user visiting webapp.com FIRST, then directing to portal.com to login, then redirecting back. But in my user story, the user visits portal.com first and is already logged in when they are linked to webapp.com).
Apologies if my terminology is poor - I am new to this area.
Cheers,
Ollie
Technically OAuth 2.0 has been created as Authorization protocol, but it is easily usable for Authentication (Identity Provider) as well and suits your situation rather well. You may however investigate OpenID Connect (OIDC) - which is an extension of the OAuth 2.0 exactly in the area of Authentication / Identity Provider.
If you have got a User Session on your Portal, then it is absolutely fine if you simply redirect to your WebApp and then the WebApp (which has no session yet) requests User Identity from the Portal by the means of OAuth 2.0 / OIDC. User would get extra 2 redirects without noticing anything but this way the login would also work fine if user bookmarks your WebApp and accesses it without first entering portal.com.
It sounds you are looking for a solution of single sign-on. If so, OAuth 2.0 (RFC 6749) cannot help you. OAuth 2.0 is a specification for authorization, not for authentication. It explicitly states as follows.
The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
Authentication deals with information about "who one is". On the other hand,
authorization deals with information about "who grants what permissions to whom". So, OAuth 2.0 is not the keyword for your case.
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