I am trying to understand what are the steps involved in enabling HTTP artifact binding in ADFS 3.0 that could resolve my SAML assertion sending via GSA (Google Search Appliance). I need to provide an "Artifact Resolver URL" to GSA. so I need to know what steps are involved in ADFS 3.0 to make this URL working.
I see below document that talks about this in section 4.8, but that did not help me and also it is for ADFS 2.0.
http://download.microsoft.com/documents/France/Interop/2010/Using_ADFS2_0_For_Interoperable_SAML_2_0-Based_Federated_SSO.docx
https://SAML-hostname:port/saml-bridge/Resolve.aspx
The steps for ADFS 2 and 3 are much the same.
You have to run ADFS on SQL Server not WID.
The process is described here: SP-initiated Single Sign-On POST/Artifact Bindings.
Also ADFS is a SP not an IDP in this scenario.
Basically:
ADFS send AuthnRequest
User authenticates on IDP
When ADFS gets successful response, sends artifact to IDP by back-channel WS-Trust SOAP connection
IDP replies with assertions (claims)
Related
We have an MVC application (<myapp.somedomain.com>) .net 4.5.2 (OWIN/ADAL) that uses ADFS2016 for AuthN/AuthZ via OIDC/OAuth2. Users' credentials and attributes are stored in AD LDS. A client (X) requested to authenticate in the application via their IdP over SAML2. Is this possible WITHOUT making changes to the application?
The flow I am looking for; for this client the app’s URL would be (<myapp.somedomain.com/?client=x>). Our ADFS would recognize and redirect the client to their IdP where they would authenticate and than they would be send back to our ADFS along with some predefined claims. Our ADFS would map these claims to an Id Token / Access Token for our application to use. Am I dreaming or is this indeed feasible?
Any links to articles / documentation on how this could be achieved would be most helpful.
As #Wiktor suggests, you could add a SAML client-side stack to your app.
The other way is to federate ADFS with the SAML IDP.
When the user is redirected to ADFS, they use Home Realm Discovery to either redirect to the SAML IDP or authenticate on ADFS directly.
ADFS should handle the token conversions but you may have to fiddle around with the claims rules.
This observation pertains to CAS 5.3.9 and the documentation under https://apereo.github.io/cas/5.3.x/installation/OAuth-OpenId-Authentication.html
There is no mention of a /callbackAuthorize endpoint and yet I am seeing this in my implementation of an Authorization Code flow. Here is the sequence of requests (we are assuming the user is already authenticated to CAS):
REQ: GET https://localhost:8145/api/profile (a protected endpoint of my application)
RESP: 302, Location: https://cas-server:8443/cas/oauth2.0/authorize?response_type=code&client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf
REQ: GET (URL above)
RESP: 302, Location: https://cas-server:8443/cas/login?service=https%3A%2F%2F172.16.238.10%3A8443%2Fooscas%2Foauth2.0%2FcallbackAuthorize%3Fclient_id%3Dclient1%26redirect_uri%3Dhttps%253A%252F%252Flocalhost%253A8145%252Fcallback%253Fstate%253Dcsrf%26response_type%3Dcode%26client_name%3DCasOAuthClient
REQ: GET (URL above)
RESP: 302, Location: https://cas-server:8443/cas/oauth2.0/callbackAuthorize?client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf&response_type=code&client_name=CasOAuthClient&ticket=eyJhbGciOiJIUzUxMiJ9.ZXlKNmFYQWlPaUpFUlVZaUxDSmhiR2NpT2lKa2FYSWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wLi5RdURKNXBJZ21zOU1LcldqSmwxMk5BLnRXb3FrSEFIRzcyY2M3U3k4cm9fR0VCS05feThtVjREazBYNU81NVNVY3g0NEFlby1Kc2R3NGszNUM3X1dDVkwuM01Pd3c5ci1mVS1QelROWDVIZkJSUQ%3D%3D.b4rotud6-2s3tOU21-Y0xclwVkVEioTLhiyRhi5VotNfjzt5vKoM2Ix9Hy_OW9KSpuGMqWsBbFOtR9K2B8E6dw&lang=de
REQ: GET (URL above)
RESP: 500, Internal Server Error (cas server log shows SSL Handshake exception, probably the server tries to access a URL he has no certificate for in his truststore)
My questions:
1) Is there any documentation for the /oauth2.0/callbackAuthorize endpoint?
2) Why is the CAS server issueing a ticket in an OAuth2 flow? Should he not produce an access token instead?
3) Where is the parameter client_name=CasOAuthClient coming from? Is the CAS server trying to act as an OAuth2 client?
1) Is there any documentation for the /oauth2.0/callbackAuthorize endpoint?
Yes. See this link for general design notes, and then take a look at how pac4j works.
2) Why is the CAS server issueing a ticket in an OAuth2 flow? Should he not produce an access token instead?
No. Authorization code flows issue ATs via the access token endpoint. If you need ATs from the authorization endpoint, you need to use a different grant type. See the OAUTH spec for more.
3) Where is the parameter client_name=CasOAuthClient coming from? Is the CAS server trying to act as an OAuth2 client?
From the above link,
... almost all protocols supported by CAS operate with the same exact intentions. A given CAS deployment is equipped with an embedded “plugin” that knows how to speak SAML2 and CAS, OAuth2 and CAS, or OpenID Connect and CAS or whatever. The right-hand side of that equation is always CAS when you consider, as an example, the following authentication flow with an OAuth2-enabled client application:
The CAS deployment has turned on the OAuth2 plugin.
An OAuth2 authorization request is submitted to the relevant CAS endpoint.
The OAuth2 plugin verifies the request and translates it to a CAS authentication request!
The authentication request is routed to the relevant CAS login endpoint.
User authenticates and CAS routes the flow back to the OAuth2 plugin, having issued a service ticket for the plugin.
The OAuth2 plugin attempts to validate that ticket to retrieve the necessary user profile and attributes.
The OAuth2 plugin then proceeds to issue the right OAuth2 response by translating and transforming the profile and validated assertions into what the client application may need.
Also, extracted from this link:
... all protocols are clients of the CAS server that interact with it using the CAS protocol. This is done at the request/browser level, as opposed to doing things internally via heavily customized webflows and such that would be entangled with one another. The protocol modules that exist in CAS make zero assumptions about the internal inner workings of the CAS authentication flow/engine. They treat it just like they would an external CAS server; the only difference is, they sit and live inside the CAS server directly and yet they remain completely agnostic of that fact. Simply put in our example, the SAML2 module basically says: “this incoming request needs to be authenticated. So I’ll route it to a CAS server for authentication and when it comes back, I’ll do my bit”.
Configuration: We are using Identity Server 3 with a Web API 2 application, a mobile phone application and an upstream identity server.
Problem: The upstream identity server supports OAuth2 but not OIDC.
Question 1: Does Identity Server 3 support OAuth2 without OIDC to the upstream identity server?
Question 2: Do I need additional configuration to make OAuth2 work without OIDC?
Just to give a bit of understanding about OAuth2 and OIDC:
OIDC is extension of OAuth2. OAuth 2 isn’t about authentication. It’s all about authorization. https://www.rfc-editor.org/rfc/rfc6749 OIDC is a simple layer on top of the OAuth 2 protocol that deals with the end user. http://openid.net/specs/openid-connect-core-1_0.html
I’m not exactly sure about your implementation detail but Identity Server 3 supports OAuth2 as well as OIDC and it all depends how the client is setup (flow) and what the client asks in terms of a “ResponseType” as part of a token request to Identity Server 3.
I know this may not be an answer to your 2 questions but I think you need to think of the interaction between the Client (mobile phone application), Identity Server 3, and the Upstream Identity Server. If the Upstream Identity Server does not support OIDC then it does not care about authentication of the end user and therefore I would think that it only requires some sort of clientId/clientsecret that could be passed as part of the request to get a token? Machine to machine (Client Credential Flow). So maybe your mobile phone application calls the Upstream Identity Server in a different fashion then it does Identity Server 3? Hope this helped a bit. Cheers
I'm working with a client who would like to authenticate with Active Directory Federated Services using SAML. As it was explained to me, the client ADFS server is the SAML identity provider and I simply need to provide a webview in the app for them to load a login page. Upon successful authentication the response should give authenticated metadata?
I've tried researching SAML and iOS and have only been able to find third party software which offers solutions, but no explanation of how this may be done without any third party integration into the app.
Resources I've looked into:
https://www.mutuallyhuman.com/blog/2013/05/09/choosing-an-sso-strategy-saml-vs-oauth2/
http://leandrob.com/2012/02/request-a-token-from-adfs-using-ws-trust-from-ios-objective-c-iphone-ipad-android-java-node-js-or-any-platform-or-language/
http://blog.centrify.com/ideal-solution-for-sso-across-native-mobile-applications/
https://msdn.microsoft.com/en-us/library/bb897402.aspx
Since I don't know anything about the content of this login page, how do I determine if the response has authenticated correctly? Additionally how do I extract and pull relevant information from this response into the app to store for future authenticated web service requests?
If the customer has ADFS 2012R2, it supports OAuth for public clients. Use the ADAL (Active Directory Authentication library) that supports ADFS. In this case, it will pop up a browser dialog window to do the authentication and then get a an authorization code. This code is then converted to an access token (JWT) which can then be used against a WebAPI.
I have an ASP.NET [MVC] application which has a claims based authentication scheme running. ADFS authenticates users and redirects back to the application domain with relevant token.
Now, I'd like to simulate this process from start to end. I was able to get a SAML 2.0 token object of type GenericXmlSecurityToken from ADFS via some powershell scripting but couldn't figure out how to create an SSL tunnel and pass the token to the application just to download the Index view. Any use of net.webclient ?
You have to send SAML 2.0 token to some SP application according with SAMLP standarad.
First, that application have to know how to handle SAML tokens. Second is to send it properly. If you want to send authentication response per instance you have to create HTTP POST request to your application on specific address where it is expecting it.
Take a look over SAML protocol documentation.