Help! :) I'm having no end of problems trying to get the following working(apologies in advance if I'm not using the exact correct terminology) :)
I need to get a .NET web application (client) communicating with Weblogic web services secured with SAML 2 policies. There are restrictions in that I need to use .NET 3.5/4 and as such am using WIF (with the extensions) to work with ADFS2 configured to generate SAML2 tokens.
The website -> adfs2 -> SAML2 token bit is working fine so far - I definitely getting tokens through.
Additional(1) - the Weblogic services have to use SAML2 policies that implement a sender-vouches confirmation method and although ADFS 2 supplies bearer by default, I am able to manipulate the SAML assertion before we send the token across the wires to the service(s).
Additional(2) - For numerous reasons, the webservices are not reached over SSL and basicHTTPBinding is my only option.
Now the problem.. I just can't communicate with Weblogic in such a way as to send the token in the request (any logged attempt returns an oracle "General Web Service Security Error" due to there being no valid security header in the request). The preferred approach would be via WCF, using a channel factory - the code below is a rough example of what I've tried - the claimsidentity/token stuff was taken from the code sample that came with the WIF extension stuff:
IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity;
Saml2SecurityToken token = identity.BootstrapToken as Saml2SecurityToken;
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.Security.Transport.ClientCredentialType = HttpClientCredntialType.None;
EndpointAddress address = new EndpointAddress("http://someaddress");
ChannelFactory<weblogicService.MyService> factory = new ChannelFactory<weblogicService.MyService>(binding,address);
factory.ConfigureChannelFactory<weblogicService.MyService>();
factory.Credentials.SupportInteractive = false;
weblogicService.MyService proxy = factory.CreateChannelWithIssuedToken<weblogicService.MyService>(token)
proxy.DoSomething();
The answer at the following post (and everywhere else I've been able to find):
WCF and WebLogic SAML interop
..is exactly what I'm doing - but whether viewing the traffic with WireShark OR by implementing a customer MessageInspector and looking at the request in "BeforeSendRequest", I can't see any sign of the token (and the request is rejected as a consequence).
Also it doesn't matter if I manipulate the token to include sender-vouches or just leave it as it is originally.
Additional (3): I have been able to successfully communicate with the Weblogic service if I don't use ADFS2/SAML/WIF/WCF etc. but instead, go via a more basic WSE2.0/3.0 web references approach (i.e. creating SoapRequest, UserName token etc..)
The problem with that, is in supplying a valid username and password without user interaction. In other words, keeping a "SSO approach", and not have to implement Forms Authentication (or equivalent) to get the user credentials each time.. There doesn't appear to be any obvious way of using the SecurityToken generated by ADFS with WSE either..
Can anyone help shed some light? Why the WCF channel factory approach with a supplied token is simply not working i.e. no sign of a valid token when debugging and certainly no valid SAML token being received by Weblogic.
I have also looked at going the CustomMessageEncoder route, and adding the SAML Assertion into the SOAP header that way.. but from what I have been able to find out, it really shouldn't be this difficult. Is something in WCF broken?
End point binding limitations (basicHTTP) doesn't support SAML2 afaik, also ADFS2.0 only seems to supply bearer tokens and modifying the token after the fact is also non starter (the suggested overrides in WIF to do this don't seem to work as expected) and finally because the web services aren't behind https, having a security mode of none (which is the only one that could be used) meant no token was being sent anyway.. ahh well, back to the drawing board!
Related
I'm trying to call an Azure API App configured with Azure AD authentication. Assume for the purposes of this question I cannot use the Azure SDK and need to write code to get a token and insert it into the API request.*
I have established that there are two modes - 'client flow' and 'server flow', where client flow entails following at least one redirect to an issuer to get a token, and server flow where the server does this for you. Since I'm talking about doing this in code, following redirects would be possible but fiddly, so I'd prefer to use a mode where the URI or URIs to visit are known ahead of time and return content, rather than redirecting. The following diagram illustrates how the gateway routes all requests.
I think the mode I need is client flow, which would go something like:
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
Pass the access token to the gateway (in what format?)
Receive another token in the gateway response
Supply this token in a header when making an API request (which header?)
How am I supposed to do this? The Azure documentation doesn't give enough detail about how it works, and expects all users to just use the SDK, which hides what is actually happening.
The actual reason is that ultimately this will need to be called from BizTalk, which uses the WCF WebHttpBinding to call restful services. I'm writing a custom behaviour to insert a token header into the request, but I need to know how this token should be acquired. It's possible to run arbitrary code in BizTalk but trying to do this makes the solution complicated, and config-only or mostly-config with minimal, loosely-coupled code is the simpler solution
Just want to understand your scenario better, Because you are going to use it from BizTalk Receive Pipeline, The scenario can be simplified by enabling a customer authentication token right ? Basic username and password for your API you have hosted on the cloud. Does BizTalk want to authenticate it self with tokens for each AD User ?
To answer some of your questions
Get an access token from the identity provider (which is what? how do I find out where this resides? what is the format of the request I have to send to the IdP?)
After you have configured your AD configuration, Once you have completed the authentication, I am assuming your are using ASP.Net here, You can find everything you need about the claims on your Thread.CurrentPrincipal, You can convert it to ClaimsPrincipal like so var claimsPrincipal = Thread.CurrentPrincipal as ClaimsPrincipal; and then you will find a lot of good information on this object. Name of the user logged in, list of claims the principal has etc. I have not explored every avenue here, but this should be a good starting point.
Your API App is running on this process which means you have access to these claims in your API App code as well.
I would build a custom pipeline in BizTalk that uses Azure SDK to authenciate and build this scenario, it is a bit complicated but it will give you more control over what goes through the pipeline as well when authentication fails with permission issues and so on.
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
I have created a Security Token Service (STS), an service with a reference to the STS and an example desktop application.
This works as expected when using Windows authentication and Message security, a token is retrieved from the STS and the service method is called successfully. The service returns a string containing the current users identity, which returns my AD username.
I have a requirement however to authenticate against a database rather than AD. I have tried creating a CustomUserNameValidator (in the STS, is this the correct place?) and referencing it in the web.config. I then provide the credentials as shown below.
SampleServiceReference.SampleServiceClient client = new SampleServiceReference.SampleServiceClient();
client.ClientCredentials.UserName.UserName
= "alex";
client.ClientCredentials.UserName.Password
= "pass";
I believe the certificates are set up correctly (all using 'localhost'), however I receive the following exception when calling the service:
System.ServiceModel.FaultException: ID3242: The security token could not be authenticated or authorized.
Whatever I try seems to fail. Is what I am describing even possible? Does the service client also pass the client credentials through to the STS, or am I completely misunderstanding what is happening here?
This stackoverflow question is similar, however I have checked the audience URL and it seems ok. WIF STS ID3242
Has anyone got any advice on how I can achieve custom authentication when using a STS?
Update: the code samples referenced below are not available anymore (Codeplex doesn't exist). The book download does and it is here: https://www.microsoft.com/en-us/download/details.aspx?id=28362
There's a simple example of what you need here: http://claimsid.codeplex.com
Look at either sample 8 or 4.
Small clarification though. The username/password authentication is on the STS, not on your service. Your service will authenticate with a security token obtained from the STS.
Have a look at StarterSTS.
The full source code is provided and it authenticates against the standard aspnetdb roles based SQL DB. There are a number of videos to help you get it up and running.
This project was then turned into ASP MVC - IdentityServer. This isn't quite as mature wrt the help files etc.
I am working with WCF Webhttp services. I have created a bunch of services and all that remains is to put in user authentication...
Questions
Keeping with the rest architecture style, should I authenticate each service call against the user db.
If so, I should just do authentication by supplying the credentials and password each time the service is called and make it secure with SSL. Basically, each webget/webinvoke function should contain the user credentials as parameters and I authenticate each call. Is this right? This seems rather inefficient.
Using session key somehow seems wrong but any pointers as to how to use Session in WCF Webhttp?
I am not working with ASP .net membership (will be looking into it soon) since I was working with Mysql and have my own registration/user database created. Should I be looking at that? Can I use a wcf authentication service along with wcf webhttp services?
Any literature on handling authentication in WCF webhttp services would be greatly helpful.
Many thanks
You can check Chapter 8 of RESTful .NET book (Amazon, Google books)
You will authenticate only the first call from the user, any subsequent calls will use the context of the authenticated user. There are several options how you can use SSL(TLS), like always or just when you send username/password.
I am not sure where exactly and how you store the authentication token (like in Session or similar type).
You don't need to use ASP.NET membership provider, in fact you may not use any membership provider at all, just use other authentication models. Usually, there will be only one authentication model per service, like you get the credentials, check them against persisted storage, if valid you set the security token and that token is used for all the next calls for a limited amount of time.
(I tried searching, but couldn't find any truly helpful links.)
We are implementing a set of WCF services. What I would like to do in these services is have the clients (which will be trusted application servers) be able to pass a token of some sort to the web service to authenticate. I do not want to be required to pass username/password on the initial or subsequent requests (because in some cases the calling application server may not have the password). Windows and Kerberos are not usable in our specific circumstance.
I had thought to just create a simple custom UserNameSecurityTokenAuthenticator class and modify it so that if the password is empty, it takes userName as the string-encoded token value (obviously checking the token itself to verify that it's valid at that point), but if the password is not empty, forwarding on the username/password to a MembershipProvider for checking. Basically I'd like to overload the username/password authentication to provide for token passing as well.
Is this possible? Can I simply plug in a token authenticator like this, or is there some other simple way to "intercept" requests like this (and update the actual username value from the decrypted token)?
Or is there some other incredibly simple way to allow the client to pass a custom token and have the server accept it that I'm just missing?
If it's a fairly controlled environment and not too many clients involved, then I'd try to set up something along the lines of the B2B scenario securing the transport link using certificates on both ends.
Certificates are not bound to Windows or an AD domain, and setting them up is a one-time job.
Read more about that WCF security scenario:
MSDN: Transport Security with Certificate Authentication
Fundamentals of WCF Security: Business Partner Applications
. WCF Security How-To's