I have a setup of IdentityServer with configuration of a client with hybrid flow. Is it possible to have an ASP.NET MVC app to use this instance of IdentityServer to log-in the user without looping to IdentityServer's log-in page? That is, use a custom log-in page on the client side to get user credentials and then make a server-side connection with IdentityServer to do the authorization? Is there any sample that demonstrates this? Thanks!
From how I interpret your question, the Resource Owner Password Credential Flow seems to fit your scenario.
See the FAQ-like answer here.
"Q. Which Flow Types designed to be used ONLY in trusted environment (like backend REST API/ micro-services isolated from internet, or owned servers/devices, in general: trusted OAuth2 clients)?
A.
Resource Owner Password Credential Flow (ROPCF) [it involve human: app show its own login page then pass user/pass... to STS].
Client Credential flow [machine to machine (API to API): supply client-id and secret]."
*Disclaimer - I understand you are currently using Hybrid flow- My answer simply implies you could change your solution. If that is not possible, then I would suggest looking into multiple OAuth implementations for an MVC app.
Since I didn't get an answer for this, I'm just posting what I've found so far.
It looks like it is not possible to bypass the IdentityServer's log-in page.
For more info about IdentityServer flows see: OIDC and OAuth2 Flows
Related
I have a CLI tool that requires search access, on behalf of the user. I've set up an application on our team's workspace with all of the right scopes and configuration.
However, I am dismayed at how oppressive the OAuth access token process is for CLI tools. Step 1 in their process is to provide a link to a custom web site that has an "Add to Slack" button. This already extends a simple CLI tool into requiring an entire web site, but the button is merely a static URL with parameters about the app and scopes. So far, a static page from Confluence, GitHub, or some other wiki-based project space would be enough.
Step 2 is where the user grants access to the application through their browser. However, Step 3 is where the action redirects to a special, dynamic page that requires access to take a special code, and translate it into an actual usable token for the user to plug into the CLI configuration. This extra step requires a special web page that Slack does not provide to do the translation, instead of just handing a token directly to the user.
Even worse, the API call requires secret client_id and client_secret parameters that would be plain as day in an shared or open-source CLI tool. (Despite the API documentation saying otherwise, both of these parameters are actually required.)
For example, Slackcat requires a one-page special web site expressly for the purposes of fielding OAuth requests. This is a web page that cannot be opened to the public because it would reveal the secret parameters. Unfortunately, Slackcat does not have the right scope levels I need, so I can't just borrow its web site for token generation.
Is there a better way to sidestep this process and allow a simple CLI tool to just get the right user access token it needs?
OAuth2 is fundamentally built around web browsers. The entire point is to allow the user's web browser to be redirected to the OAuth2 provider's website for password entry, so that the user's credentials are never visible to you or pass through any infrastructure you control.
This necessarily involves spawning a browser and sending it to a site you control to begin the OAuth2 flow by setting up state and redirecting the user to the OAuth2 provider, and then complete the OAuth2 flow by handling the redirect back from the OAuth2 provider and performing the code/token exchange. You can't do any of this with a static site, you need a web service.
Is there a better way to sidestep this process and allow a simple CLI tool to just get the right user access token it needs?
No. If there were, it would be a vulnerability in OAuth2 that should be fixed, not exploited to bypass the entire point of OAuth2.
Has anyone actually used OAuth2 for SSO within Spring Security 3?
Scenario:
I need my users to be redirected to an OAuth2 URL when they try to access any URL on my site for the first time. Once they are authenticated there, it will redirect them to a URL on my site, where I need to authorize them and create a session so that they will stay authorized on my site until they log out or time out.
I have tried several configurations in Spring Security using custom pre-auth filters, custom user details services, etc., but I cannot get the flow to work properly. I've not attached any code because I've gone through so many possibilities that I'm not even sure what to post.
I'd appreciate any direction anyone can give. Thanks!
OAuth2 isn't intended as an SSO solution. It's primarily about delegating the right to access resources on your behalf to other parties (applications, for example). So if that's not something you need then perhaps you should be looking at a simpler solution.
It's possible to use OAuth2 to allow access to a resource which provides information on your identity, in which case it can be expanded for authentication use. This is how OpenID connect uses it (by adding a userinfo endpoint resource).
You might want to take a look at the UAA project within CloudFoundry which is built on Spring Security OAuth and uses OAuth2 in this way to provide authentication services and to issue access tokens to applications within the system.
This appears to be a somewhat dead question but here are some resources that may prove useful to future searches:
#EnableOAuth2Sso
#EnableOAuth2Resource
Spring Cloud oauth2 SSO sample
Spring oauth2 SSO with a whole bunch of other stuff too
Who is your Oauth2 provider? In a case of some public one like Facebook, Twitter, Google and many others you can take a look at Spring Social project. Even if you use some private provider you can add it very easy (http://blog.springsource.com/2011/03/10/extending-spring-socials-service-provider-framework/, Developing a Netflix Service Provider Implementation section).
Spring Social is designed to cover your main case with some minor difference: by default you must submit a form to start authentication process. I think this difference may be easy customized to feet your needs.
You can play with Spring Social Showcase sample to have an idea about authentication workflow.
This is a question regarding ASP.net MVC 4. You can assume SSL throughout.
I have a Web API which will be available to clients over SSL using HTTP Basic Auth.
I also have a CMS, on the same domain, which uses the Web API via jQuery.
The user logs into the CMS over Forms auth.
For this reason I would like that it be possible to login to the Web API using either HTTP Basic Auth or Forms auth.
I plan to implement this using a custom AuthorizeAttribute, which will first check the basic auth header against the database if present. If the basic auth header is not present, then it will delegate authorization to the base AuthorizeAttribute to handle Forms auth.
First of all, is this a good idea? Can anyone see any problems in allowing either type of auth? Can anyone see any implementation problems?
First of all, is this a good idea?
Yes, it seems like a good idea and I do not see anything wrong with implementing 2 types of authentication mechanisms:
Forms authentication for users that are already authenticated on the same domain
Basic authentication for users that are not yet authenticated but posses a username and password and want to directly invoke some method of your Web API
Are there any decent examples of the following available:
Looking through the WIF SDK, there are examples of using WIF in conjunction with ASP.NET using the WSFederationAuthenticationModule (FAM) to redirect to an ASP.NET site thin skin on top of a Security Token Service (STS) that user uses to authenticate (via supplying a username and password).
If I understand WIF and claims-based access correctly, I would like my application to provide its own login screen where users provide their username and password and let this delegate to an STS for authentication, sending the login details to an endpoint via a security standard (WS-*), and expecting a SAML token to be returned. Ideally, the SessionAuthenticationModule would work as per the examples using FAM in conjunction with SessionAuthenticationModule i.e. be responsible for reconstructing the IClaimsPrincipal from the session security chunked cookie and redirecting to my application login page when the security session expires.
Is what I describe possible using FAM and SessionAuthenticationModule with appropriate web.config settings, or do I need to think about writing a HttpModule myself to handle this? Alternatively, is redirecting to a thin web site STS where users log in the de facto approach in a passive requestor scenario?
An example of WIF + MVC is available in this chapter of the "Claims Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
I do suggest reading the first couple chapters to understand all underlying principles. This blog post covers the specifics of MVC + WIF:
Link
Controlling the login experience is perfectly fine. You should just deploy your own STS (in your domain, with your look & feel, etc). Your apps would simply rely on it for AuthN (that's why a app is usually called a "relying party").
The advantage of the architecture is that authN is delegated to 1 component (the STS) and not spread out throughout many apps. But the other (huge) advantage is that you can enable more sophisticated scenarios very easily. For example you can now federate with other organization's identity providers.
Hope it helps
Eugenio
#RisingStar:
The token (containing the claims) can be optionally encrypted (otherwise they will be in clear text). That's why SSL is always recommended for interactions between the browser and the STS.
Notice that even though they are in clear text, tampering is not possible because the token is digitally signed.
That's an interesting question you've asked. I know that for whatever reason, Microsoft put out this "Windows Identity Foundation" framework without much documentation. I know this because I've been tasked with figuring out how to use it with a new project and integrating it with existing infrastructure. I've been searching the web for months looking for good information.
I've taken a somewhat different angle to solving the problem you describe.
I took an existing log-on application and integrated Microsoft's WIF plumbing into it. By that, I mean that I have an application where a user logs in. The log-on application submits the credentials supplied by the user to another server which returns the users identity (or indicates log-on failure).
Looking at some of Microsoft's examples, I see that they do the following:
Construct a SignInRequestMessage from a querystring (generated by a relying party application), construct a security token service from a custom class, and finally call FederatedSecurityTokenServiceOperations.ProcessSignInresponse with the current httpcontext.response. Unfortunately, I can't really explain it well here; you really need to look at the code samples.
Some of my code is very similar to the code sample. Where you're going to be interested in implementing a lot of your own logic is in the GetOutputClaimsIdentity. This is the function that constructs the claims-identity that describes the logged-in user.
Now, here's what I think you're really interested in knowing. This is what Microsoft doesn't tell you in their documentation, AFAIK.
Once the user logs in, they are redirected back to the relying party application. Regardless of how the log-on application works, the WIF classes will send a response to the user's browser that contains a "hidden" HTML input that contains the token signing certificate and the user's claims. (The claims will be in clear text). At the end of this response is a redirect to your relying-party website. I only know about this action because I captured it with "Fiddler"
Once back at the relying party web site, the WIF classes will handle the response (before any of your code is run). The certificate will be validated. By default, if you've set up your relying party web site with FedUtil.exe (by clicking "Add STS Reference in your relying party application from Visual Studio), Microsoft's class will verify the certificate thumbprint.
Finally, the WIF framework sets cookies in the user's browser (In my experience, the cookie names start out with "FedAuth") that contain the users claims. The cookies are not human readable.
Once that happens, you may optionally perform operations on the user's claims within the relying party website using the ClaimsAuthenticationClass. This is where your code is running again.
I know this is different from what you describe, but I have this setup working. I hope this helps!
ps. Please check out the other questions I've asked about Windows Identity Foundation.
UPDATE: To answer question in comment below:
One thing that I left out is that redirection to the STS log-on application happens by way of a redirect with a query-string containing the URL of the application the user is logging in to. This redirect happens automatically the first time a user tries to access a page that requires authentication. Alternatively, I believe that you could do the redirect manually with the WSFederationAuthentication module.
I've never tried to do this, but if you want to use a log-on page within the application itself, I believe the framework should allow you to use the following:
1) Encapsulate your STS code within a library.
2) Reference the library from your application.
3) Create a log-on page within your application. Make sure that such page does not require authentication.
4) Set the issuer property of the wsFederation element within the Microsoft.IdentityModel section of your web.config to the login page.
What you want to do is an active signin. WIF includes WSTrustChannel(Factory) which allows you to communicate directly with the STS and obtain a security token. If you want your login form to work this way, you can follow the "WSTrustChannel" sample from the WIF 4.0 SDK. Once you have obtained the token, the following code will take that token and call the WIF handler to create a session token and set the appropriate cookie:
public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}
Once you have done this, your site ought to behave the same as if passive signing had occurred.
You could use the FederatedPassiveSignIn Control.
Setting your cookie like this:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens't work for SSO to other domains.
To cookie should be set by the STS not at the RP.
I am putting a plan together for a series of sites that will share user account information among them. The idea is that once a user logs in using their OpenID, they can access any of the sites and it will know who they are.
What are the common patterns/best practices that i could employ to achieve this?
If all the sites share a common hostname in their URL then you can set an auth cookie (FormsAuthentication.SetAuthCookie) specifying the path of the cookie to be "/" so that all sites can see the user is logged in.
If the sites are not sharing a common host name, I think the only way to get a truly "once signed in, signed in everywhere [within your ring of web sites]" would be for all authentication to happen at just one site (perhaps one dedicated to authenticating the user) and for the other sites to redirect the user to that site for authentication and then that site would redirect back. In essence, that auth site becomes an identity provider, and almost exactly fills the role of an OpenID Provider (in fact DotNetOpenAuth could be used here for this exact purpose). Since it sounds like your goal is to let the user log in with their OpenID, your OpenID Provider on that one auth site could itself use OpenID to authenticate the user. Your own pure-delegation OpenID Provider could be written such that it always responds immediately to checkid_immediate requests as long as the Realm in the auth request is one of your trusted ring of sites. Thus you could effect single-sign-on across all your sites.
Please consider the following Patterns & Practices on Web Service Security from Microsoft:
Brokered Authentication - http://msdn.microsoft.com/en-us/library/aa480560.aspx
The main topic is - Web Service Security
Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
http://msdn.microsoft.com/en-us/library/aa480545.aspx
Ultimately theres lots of ways you could do it. I achieved a simple single sign on by building a url with a token from one website pointing to another domain. The encoded & encrypted token contained details to submit back to the previous domain. Upon receiving an incoming request on the second domain, an underlying web service checks that the incoming request's token is valid with the previous domain using a shared private secret, known to both domains.