I am looking for an example of using Duende Identity Server as the SP for handling SAML Assertion coming from a 3rd party IDP Initiated SAML
A client wants to send us a SAML assertion to handle on our side so identity server is not the SP
Does it matter that we use Duende Identity Server as our internal IDP
How would we modify the start-up to work with the SAML request coming in ?
Related
I need to develop set of microservices (rest APIs) which is to be used by web and mobile client, the microservices are sitting behind API gateway, I've to integrate with SSO (using SAML) for user's authentication, I understand that SAML token to oAuth2 token conversion has to be done so that I can verify auth token at API gateway and handle authorization there itself, but the piece which is not clear to me is that who will take care of conversion of SAML token to oAuth2 token, is it IDP who provide this functionality out of box or do I need to built up something of my own?
One possible solution which I'm thinking of is
User (from web/mobile) sign in via SSO
Gets SAML response from IDP
Send that SAML response to server to generate Auth Token
Server gets request to generate auth token, looks for SAML response and validate it against IDP
If SAML response is valid then generate auth token and send it back to client
On subsequent API request from client the token is passed as header which API gateway validates
The thing is I'm bit reluctant to implement SAML and oAuth thingy myself and looking for some ready made solution but couldn't find any, can someone please suggest of any library solving this problem, thanks in advance.
It feels like your approach is correct - it is the role of the Authorization Server (AS) to deal with SAML login integration for you. Only configuration changes should be needed, though of course you need to use an AS that supports SAML integration.
Your UIs and APIs will not need to know anything about SAML and will just use OAuth tokens. There should be zero code changes needed.
Most companies use an off the shelf AS - eg from a low cost cloud provider. My Federated Logins Blog Post summarises the process of integrating an IDP. The walkthrough uses AWS Cognito as the AS - and the IDP could be a SAML one.
I maintain a microservice that sounds like it could help you - https://github.com/enterprise-oss/osso
Osso handles SAML configuration against a handful of IDP providers, normalizes payloads, and makes user resources available to you in an oauth 2.0 authorization code grant flow.
Osso mainly acts as an authentication server though - we don't currently have a way for your API gateway to verify an access token is (still) valid, but that would be pretty trivial for us to add, we'd be happy to consider it.
I'm looking to implement a plugin using OpenSAML for a 3rd party application that will enable the application to be treated as a SAML Service Provider, so that I can integrate it into AWS SSO.
The following image describes the SAML authentication process when the Service Provider (SP) and Identity Provider (IdP) use HTTP Artifact binding (taken from here):
After the initial authentication, the SP returns the protected resource to the user. My question relates to how subsequent requests for protected resources are processed.
With OIDC, the browser would receive a token and this would be sent to the SP for subsequent requests. The SP can inspect the token and confirm its integrity (assuming it is signed) and validity, without needing to make further calls to the IdP to re-authenticate the end-user.
With SAML, how do I achieve the same effect? How do I not have to make repeated calls to the IdP to check identity?
I suppose I could use a session, but I don't understand how I might ensure that such information is not tampered with within the client (i.e. how does the SP not have to rely on information provided by the client?). Does SAML have some sort of concept of a token that is safe for the user to store (the HTTP Artifact binding explicitly restricts the user from seeing the response from the IdP)?
What happens after the last step is not defined in the spec. You could say it's formally outside of SAML protocol. Even the last protocol-formalized step of SP supplying the resource is essentially a "do it yourself":
Section 3.4.5 (HTTP-Redirect binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.5 (HTTP-POST binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.6 (HTTP-Artifact binding):
[you can probably guess by now]
Most SPs will drop one or more cookies on the client during that last step. One of those cookies will contain a session ID or a more generic pointer that can be used to locate a session when sent back to SP. Subsequent resource "authorization" requests to SP will proceed by having the SP consult this server-side session. The session will usually hold the (authenticated) security context for this user/client.
For example, Shibboleth (built on top of OpenSAML) does so. The content of the cookie is up to the SP. It's arguable that token-based auth via e.g. local storage is more secure vs a cookie. There are pros/cons to both options and many factors specific to use case/context/technology stack impact the evaluation of risk and associated threat model.
Note: AWS SSO does not support the Artifact binding.
I have an ASP.NET Web API (v4, specifically) application that currently authenticates using Forms authentication (through a SQL membership provider (i.e. using aspnet_Membership, aspnet_Users tables and all that)). It's basically the backend API hub for a bunch of other applications.
Alongside that, I have a third-party application, SP (for service provider), which supports SSO and single logout using SAML. My goal is to set up a SAML identity provider that can receive a SAML single logout request, which would in turn send a logout response to SP.
I started out looking at Auth0 to achieve this, but I am confused about what role Auth0 would actually play as the identity provider since all of my user creds are stored in my own database. Is there some way I can supply Auth0 (or any of these identity providers) with my user creds store for it to authenticate my users? Or is this not desirable/possible and I need to make my existing app to be the SAML identity provider?
To use SAML in your client application, you need a SAML stack.
So you could add the stack and it would be self-contained.
Both identityserver and Auth0 can use a SQL DB as the authentication store. They both support the SAML protocol.
Once you have done the SAML configuration, you just need e.g. a login screen where the users decides local authentication or SAML authentication (this invokes the IDP and that would do the SAML side for you).
Currently, I'm using spring-security-saml2-sample project(V1.0.1) as an SP, and Shibboleth as an IdP. I've implemented the Web SSO profile and trying to write an ECP client to make ECP profile work. However, I found limited documents about ECP profile in spring security saml(Ref doc Chapter 10.4)..
I found two useful ECP client samples in github:
github.com/spaetow/ShibbolethECPAuthClient
github.com/DARIAH-DE/shib-http-client
After enabling PAOS binding and "ecpEnabled" in SP's metadata generator, I wrote some sample ECP client code refering to the above two project, the main flow is:
Send a Get request to "localhost:8080/spring-security-saml2-sample/saml/login" with PAOS related header.
Get the response(SAML Request) and generate a SAML Envelope.
Use the new generated SAML Envelope to Post to Shibboleth IdP(https://exampleIDP/idp/profile/SAML2/SOAP/ECP), with UserName/Password in Authorization Header(basic authentication).
Shibboleth authenticate and response with SAML Assertion(Also an SAML Envelope).
Send the SAML Assertion(Envelope) to SP: "localhost:8080/spring-security-saml2-sample/saml/SSO" and get response.
I think I've succeeded in the first four steps, Shibboleth can authenticate the user and send the SAML Response. But I've got some problems in the 5th step. And even some examples end in step 4.
I found that, spring security saml gets the 5th request and tries to Authenticate the SAML response just like WebSSO profile does. The logic is in "org.springframework.security.saml.SAMLProcessingFilter". After parse the saml response and get the Authentication, the response will be redirect to a default target URL"/". The logic is in AbstractAuthenticationTargetUrlRequestHandler.handle(req,resp,authn). So, I can only get an 302 HTTP response in the ECP client.
Here are my questions:
I want to get user information in the 5th step, do I have to write another filter instead of "SAMLProcessingFilter" to send the Authentication as response? Or is there any other ways(I think ECP client cannot parse SAML Assertion received in Step 4)?
In this situation, my ECP client likes "Rest client" very much, because I have not record any cookies in my code. So after the 5th step(after login), how can I access the SP again for another resource? Does that mean I have to record the JSessionID cookie in the ECP client?
Is the theory of SAML SSO(WebSSO) like Jasig CAS(Use cookie/session)? If so, in the ECP mode, How can I single sign on two ECP clients(each connect to different SP but SP cpnnect to the same IdP). Or, can I make SSO in a ECP client and a browser?
Thanks in advance!
I am trying to implement SAML SSO between two J2ee applications (form-based) deployed on two different instances of WAS, I have configured both WAS instances as service providers using the steps in http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_enablesamlsso.html
I set the property sso_1.sp.login.error.page to the login page of the Identity provider but when I get redirected to the login page, it displays that no SAML request (AuthRequest) is available, can anyone tell me why the WAS is not issuing the SAML authentication request?
WAS does not send a SAML request in the redirect. This is explained in the paragraph above this section of the DeveloperWorks SAML TAI article. The scenario you're expecting is referred to as the solicited response. WAS only supports what the article terms the unsolicited response. In this latter case, the IDP must understand how to authenticate the user (usually through a browser interaction) without a SAML request.