We're implementing a web SSO solution using PingFederate, with a 3rd party product that includes SAML2 out of the box.
However we're trying to work through the question of how to stop the IDP session timing out if the user is still actively using the SP.
The 3rd party product supports requesting an empty resource on the IDP side, with the intention that this URL would result in the IDP session being extended.
I can't see anything in PingFederate that supports anything like this. Does anybody know how this is generally resolved? Is there a way to extend the PingFederate session e.g. API call, HTTP POST to an endpoint, whatever?
Or does the SP need to construct a new authenticate request? If so, does this result in a new SAML response / token being issued with a new NotOnOrAfter date?
Unfortunately, this isn't a use case that SAML 2.0 covers and any solution that fits within the SAML 2.0 spec will probably be custom to an individual product. Additionally, is no way to have the SP extend the session at PingFed (IDP) except to do another round-trip for SSO.
Typically customers handle this by making the session at the IDP long-lived so that user's are not prompted to login again when switching between SPs.
If you control both the IDP and the SP, then I'd recommend looking at using PingAccess in conjunction with PingFederate. You can still Federate into the application via PingFed but PingAccess will allow you to manage the sessions across applications.
Related
Hello I manage 2 Liberty servers that serve UI and BFF content respectively and I want to secure them both with corporate oidc OP. Having heard about inbound propagation, I was thinking in propagating the access token from UI to BFF.
However I didnt find documentation on how should I configure it to outbound propagate the access token after successful authentication. The documentation only refers to inbound propagation. Only thing I see is a WASOidcClient_*** cookie being set, which I know nothing about it.
I also heard about jwtSso-1.0 feature and tried to create my own JWT with the necessary user information, but can't make this feature get the desired claims from the ID Token (already opened this other question).
So I'm unclear of:
Am I designing this correctly?
How can I get the UI Liberty propagate access token after successful authentication, preferably without coding anything?
Should I propagate access token, or IDToken? BFF needs basic user information that is present in IDToken
What is the WASOidcClient_*** cookie for? Can it be used by different Liberty instances to authenticate requests? Is the name configurable? Im just curious, because this cookie is probably proprietary and not portable, not much desired.
Appreciate it in advance!!
We have to integrate third party SP for SSO. Our application is a wrapper in spring(not springboot) and it has authentication/authorization module calling backend service using mongo as DB.
Now the requirement is to integrate SSO SAML based SP with a third party. The third party has given docs which asks to have IDP. In the provided requirement from SP, Nameid assertion has to be persistent ,unique and opaque and can be userid of client application (our application).
I believe we have to have an IDP like SSOCircle or Okta or some open source IDP in order to integrate with SP. And I think we can write a separate springboot SAML IDP and expose api to our legacy spring for login to SP.
Flow as I understand:
User from our portal access the third party SP website or API.
Third party SP will redirect the user to our IDP to log in .They will save NameId(UUID mapping of userids or userids) at their end which they will pass as SAML request along with other assertions.
Once User is successfully logged in , our IDP will redirect the user to third party SP with success response.
My questions :
Can (or should we )we bypass IDP ? I guess this would mean we write SAML IDP on our own. Please let me know my best options or whether this is a good idea to go without IDP and write our own equivalent.If we can't, I would assume we have buy paid proprietary or use open source IDP.
Nameid (unique, persistent, opaque) assertion : This is one of SP requirement.If we have to use IDP (which I think), and it SP consumer assertion requirement is to use persistent Nameid to be passed.It should be unique, persistent and opaque . So we are thinking that UUID mapping of userids in SAML request to IDP should be OK. If we go like this, we have to store UUID mapping in DB as nameid assertion . Do we have to use just our portal userids as nameIds or UUID in DP -SP integration to satisfy requirement? Please comment what approach is right.
Nameid persistence restrictions at IDP end as well as at SP end:There is one bottleneck at our end.Our IT security team would probably not allow NameId persistent mapping UUID forever due to security concern, In that case NameId mapping will change at our end. How should be address this if we have to use UUID as nameid?
NameId provisioning : when user from our portal request to login to SP - Would it be passed to SP as login request and then SP constructs saml request and pass nameids assertions to IDP ? If yes ,what is best approach for nameids be passed to SP as login request ? If no, how will SP know what UUID to pass in SAML to IDP? How will we address this if the mapping nameid are UUIDs which could change due to security concerns? . Another thing is though nameid is mentioned is mentioned as "persistent" in requirement but in the examples of requirement doc they are showing urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified . I think thats probably a mistake in doc. [?].
Any sample SSO SAML IDP (client ) application which we can refer which is close to above 1 ) and 2)?
Can (or should we )we bypass IDP ? I guess this would mean we write SAML IDP on our own.
No, you can't. If the 3rd party acts as a SAML Service Provicer, you need to or act as a SAML Identity Provider. Building your own implementation is quite a big tasks and you may either use an SAAS-based IdP like SSO Cirle (keep in mind that your customer needs to accept where the user idenity data is stored) or deploy your own SAML IdP. There are payed products/service or free-of-charge. Open source need not mean free-of-charge , that's often misunderstood.
If you need a SAML IdP anyway, you may think of making your own app act as a SAML SP as well to leverage authentication of the IdP.
Which NameId format to use is kind of agreement. The SAML spec propose the usage of specific NameId format for specific purposes, e.g.
'transient' NameId format is meant to be used for SSO flow only.
'persistent' is meant to be used when you want to link identities of different identity silos together
The SP may use the value of the NameId value in the subject to find a user's profile or to perform auto-federation (build a profile on its side). It could also use attributes from the SAML attribute statement to achieve the same. Many SP implementations offer this.
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've been working whit the SAML extension to connect to an ADFS server. I've hacked the sample application to use my ADFS server and everything went well, but I would like to know if there is a way to connect to an IDP without using the loging page of the IDP. I mean if there is a way to do this process in background for the end-user. I am thinking about doing a query to ADFS or something like to get the users and do authentication from the SP login page, avoiding the need for the user to authenticate in the IDP login page.
The purpose of federated authentication is to delegate it to a centralized server in such a way that the relaying parties/service providers do not have access to user's credentials. Enabling authentication directly in your application would violate this principle and for this reason is not supported by neither Spring SAML nor ADFS.
If you want to authenticate your users directly, use authentication directly against Active Directory instead of ADFS. This will fully support your use-case.
I am starting a new project where we are planing to build a restful back end and an AJAX font end. I am approaching the problem by focusing on Identifying all the resources that I have and what the various HTTP verbs will do them, their URI and the JSON representations of those resources.
I am looking for the best design for securing the backend. Here is the list of designs I have considered. I am looking for alternative designs not listed below, and pros, cons recommendations. The system will be implemented with Spring 3.0 and possibly Spring Security 3.0, SSL will be used for many parts of the system but not for all of them, so some requests may come on SSL and some might not.
Option 1: Use the HTTP session
Show a standard login screen, create a server side session and let tomcat send back a jsessionid cookie and have the ajax client include the JSESSIONID cookie on every XHR request. This options just feels like it's the wrong approach for the following reasons.
The connection becomes statefull which is against the rules of REST
I want to be able to split the bakcend into multiple seperate WAR files which means i could have multiple HTTP sessions on the backend, if that is the case then this approach does not work. While I don't need the ability to split the backend into multiple apps today, I would prefer a design that allows for that possibility.
Option 2: Find an open source Java based security library that does this
Other than Spring security I have not found any other Java libraries, any recommendations are highly appreciated.
Option 3: Try to use an existing protocol like OAuth
In my very brief look at OAuth it seems that it is designed for authentication across sites where each site has it's own user database. In this system i want a global user database shared across all the backend ajax services.
Option 4: Use SAML and Shiboleth
This options seems over kill and hugely complex to setup and maintain.
Option 5: Send the username and password with every request
This requires that user sends their username and password with every request, which means that the front end AJAX app must store the username and password as a JavaScript object and if the user navigates away from the page then back the username/password combo will be gone and the user might be forced to log in again. I don't want the front end to try and put the username and password into cookie as that would comprise security.
Option 6: Implement my own authentication / Authorization protocol
Create a REST service that users can present their username/password combination to and then get back and security token, which they must send back to the service with every request. The security token would be digitally signed by the service and would have an expiry time. The token would be only good for most operations high security operations would require a new login screen as port of confirming the operation.
Problem with this approach is I have to invent yet another security protocol which seems like a total waste of time.
I am sure I am not the only person up against this problem, I hope the stack overflow community can point to some options and tools that I have not found yet.
Take a look at Apache Shiro. It is an authentication system that has a session management feature that can be used to share sessions across applications. This may be the easiest thing to do.
Or you could use Spring Security (or Shiro) with a Remember Me cookie that is shared across the webapps (as long as they are in the same HTTP domain). The remember me cookie would be analogous to your token in option 6. You can set the expiration on the cookie that so it is short lived like a session cookie or long lived like a regular remember me.
You might also want to take a look at Jasig CAS - Single Sign-On for the Web. It has a REST API and a protocol (Proxy Tickets) that allows services to proxy user AuthN to backend services like you described in option 6. http://www.jasig.org/cas
Briefly...the application that serves up the AJAX client is protected with Spring Security (supports CAS out of the box) and gets a Proxy Granting Ticket that you embed in the AJAX client. The AJAX client uses the PGT to get Proxy Tickets for your REST services...protected with Spring Security too. The REST services get an authenticated userId without every touching primary credentials.
Alternative, you could keep the PGT on the server and use AJAX calls to retrieve Proxy Tickets that are then used by the AJAX client to call you REST services.
As I understood you are going to secure a rest application, to preface you must know that a security provider consisd of three concepts (3A):
-Authentication
-Authorization
-Auditing
to implement these three together you must provide bunch of tools such as :
-SSO provider
-Session Store
-Open Id pattern
-user credentials integration
....
I have used ACL(Spring ACL) to provide authorization services and oauth2 for authentication.
there is one channel to connect these two together and its scopes(oauth2 scopes) but the problem is scopes are not flexible(pure strings) enough to implement authorization modules such as role_voter, cache_strategy, black_list or,Role_base strategy, exceptional permissions, white_list... (but you can use #EnableGlobalMethodSecurity)
In my case I used authorization server as a resource for oauth2 authentication server(take a look at http://projects.spring.io/spring-security-oauth/docs/oauth2.html), then I considered two spots to check authorization, the first I issued ACL to front-end and forced programmer to design her page dynamically up to ACL concept, the second is in back-end on service layer(BLL) using Aspect when one rest is going to be called. I sent the service key as an actee to check if current user has enough access control to do that. and for auditing you must monitor all requests I mean you must use an listener in your gateway or broker...