I would like to check my understanding of the authentication interaction between a Browser, an Application, IdentityServer and ADFS 3.0 for a federated authentication scenario.
I created the sequence diagram below after some googling and reviewing logs in Identity Server.
It seems straightforward up to step 7, but I believe I may be missing or confusing the interaction that takes place after that between IdentityServer and ADFS 3.0. For example, I can see an IdentityServer log entry that states:
Callback invoked from external identity provider
This line would seem to imply direct interaction between ADFS and IdentityServer and contradict step #9 in my diagram. So, does the browser forward the ADFS token to IdentityServer as in step #9 in my diagram, or does ADFS send the token directly to IdentityServer? If the later, where would that occur in the sequence.
Any insight would be very much appreciated!
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.
Some background
I work on an ASP.NET MVC web application which implements federated authentication using WIF.
For reasons beyond my control, I am forced to use a proxy STS which, on the one hand, serves as the IdP for my MVC app, but at the same time it implements it's own federated authentication via an ADFS server.
This way, the user authentication process in the MVC application looks like this:
User enters MVC application.
The application redirects the user to the proxy STS for authentication.
The proxy STS redirects the user to the ADFS server for authentication.
The ADFS server authenticates the user and redirects back to the proxy STS.
The proxy STS redirects the user back to the application, with the same authentication info which the ADFS server issued.
The ADFS server is not something I have direct access to (in terms of management), whereas the proxy STS is just a little service (implemented using this tutorial) which I control fully.
The problem (and what I tried to do to solve it)
Using the above setup, I noticed that the users' authentication wears off after about an hour, and then they need to be re-authenticated, so now I'm looking for a way to extend the authentication lifetime.
As of my understanding, it should be enough to extend the lifetime of the security token issued by the proxy STS, which I did. But it didn't solve the problem - the users still needed to be re-authenticated frequently.
So I tried doing the following things hoping it would help:
Setting the persistentCookiesOnPassiveRedirects option to true in the MVC application's ws-federation configuration with a 1-week long expiry time (to make sure that the auth cookie is not being lost due to session expiry).
Setting the HTTP session lifetime in the MVC app to last a week (to make sure that the security token is not being lost on the server side due to session expiry).
Setting the security token lifetime for tokens issued by the proxy STS to 1 week (which I made sure is being applied by examining the security tokens received by the MVC app).
Doing the things described in bullets 1 and 2 on the proxy STS as well.
Setting the IIS auto app-pool recycling time for the MVC app's application pool to be once a week.
None of the above didn't seem to solve the problem, but then I tried:
Setting the security token lifetime for tokens issued by the ADFS server to 8 hours.
As a result, the authentication duration got longer, even as much as 10-11 hours.
The question
What controls the authentication duration with WS-Federation in the above scenario?
Which of the above things that I tried should really be relevant to my issue, and which should not affect it at all (specifically, I would like to understand whether the ADFS token lifetime should really have any effect, and if so - why, or did I just have bad luck with my tests, and it was really something else that might have helped with the issue)?
Thanks in advance!
You have hit a lot of relevant parameters. I will talk about the WIF/.NET part and SAML Tokens only. Not about Pool recycling etc. They are different topics. You will have to take a look at the XML in the SAML messages and Tokens if you really want to control this.
One of the problems is that there are differences between SAML1 and SAML2 Tokens. Besides that some validity timestamps are in the SAML Protocol, which is not used between WIF and an IdP.
Summarized:
It appears that WIF uses Conditions for the SessionToken. That is the only thing available in SAML 1.1. OK there.
SecurityTokenHandler.ValidateToken(token) calls DetectReplayedTokens().
The SecurityTokenHandler.DetectReplayedTokens(SecurityToken) method verifies the validity if the incoming Token (SubjectConfirmationData #NotOnOrAfter). It is not present in SAML 1.1 there WIF uses Conditions#NotOnOrAfter.
This is essentially correct for Replay detection in SAML 2. Somewhat silly (too broad, too long) for SAML1.1.
Applications can (and do) override this behavior in TokenHandler(s) or in events of WSFAM and SesAM. See for instance Vittorio about Sliding Expiration.
I'm running thinktecture IdentityServer v2 with two Relying Parties in my qa environment on Windows Server 2008 R2 Standard.
IdentityServer is configured for two RPs, one using Federation the other with oAuth
My first relying party (www.sitenumberone.com) is an ASP.Net Framework 4 web site using WIF Federation.
My second relying party (www.sitenumbertwo.com) is an ASP.Net Framework 4.5 MVC 4 application using oAuth.
When I attempt to access www.sitenumberone.com I am redirected to IdentityServer login and when I am authenticated I am redirected back to www.sitenumberone.com. This part works.
My problem is, once I have authenticated to www.sitenumberone.com, if I try to hit www.sitenumbertwo.com I am redirected back to the IdentityServer login page. I would expect it not to redirect me back to the login because I have already authenticated.
I have done some research and have not been able to find a solution to this problem. Do I need to set up www.sitenumberone.com as an oAuth client in IdentityServer?
I hope someone can help.
I think you need to add some Auth Param from your request site and also on sitenumbertwo authentication method.
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
I'm working on an MVC project and I'd like to abstract authentication out completely using WIF. By default, without any additional configuration, this app needs to be it's own STS in additional to also being a relying party. Has anyone done that and have any suggestions?
I tried to think of exactly the same mechanism some time ago and I failed.
My reasoning was that to be an RP, the application has to get a signed SAML token issued by an STS. Upon receiving the token, the federation cookie is created.
But to be the STS, the application should have a login page and a mechanism to persist the login session so that users do not have to login again. Then it should react to wsignin1.0 requests and issue SAML tokens.
This leads to a contradiction in my opinion. The application should have a federation cookie (to maintain users sessions as an STS) before it issues the SAML token but in the same time it can create a federation cookie (as an RP) just after it receives the SAML token.
Of course, you could possibly maintain two cookies, a federation cookie for the RP part and a forms cookie (probably) for the STS part but it sounds impractical and against the idea of abstracting the authentication.
In a short way: this is not easily possible in my opinion. However, I would be glad to hear other ideas from someone.