I have a problem as below::
I have the application A(A is Java web application). The app A using sale the GUN for the customer.
In-App A, The user has a role:
-S(Salesperson): This is the normal user.
M(Manager): Allow the user approve when Salesperson transfer GUN to customer.
App A is deployed on Weblogic 12C.
On Weblogic, I am using SMALL to integrate with ADFS (ADFS: Active Directory Federation Services)
In the first time, the Salesperson access to application A. Weblogic is redirecting to the login page of ADFS.
After login success, Weblogic will redirect to A application.
The app A is login success.
Continue, Salesperson is transfer GUN for the customer. When Salesperson is transferring, I need to the manager to approve.
Therefore, I need to display the login form to the Manager login.
After Manager login success, if the user has a role is M, the sale person can transfer the gun for the customer. Else, I have a display error message.
My Problem:
Step 6: How can I display the login page of ADFS?
Step 7: How can I check the role of the user after login success?
Can you help me out? Thank you so much!
If you only have one application, you can't do this.
Only one person can be logged in at a time.
After that, the cookie says the user is authenticated so you don't get another login screen.
Run the application in two different browsers.
Then when the manager opens his browser, he will be asked to login.
Update
Each application is a relying party (RP) in ADFS. Each RP has its own set of cookies so they don't clash.
So configure e.g. two RP in ADFS, one for each application.
Related
We have one app and we are doing authentication through ping federate using saml. We have a button in that application that opens up another partner web application that is hosted elsewhere. What we want is to exchange the logged in user information with our partner application that gets opened up on button.
What could be possible integration approaches for same using ping federate?
The fact of the user being signed in to your app buys you nothing with respect to your other (partner) app. The partner app would have to act as its own SAML service provider. When you click on the button, you would ask Ping to send a new SAML response to the partner app, thus signing the user in over there (SSO).
I'm working on a project for an education institution and we currently have live#edu set up with the SSO Toolkit 4.5. We have a portal (home grown) that our users log in to using their AD credentials (local AD only) and then we wire up the certificate to pass up to live#edu so they're not prompted again for login creds when they view their MS mail.
MS is going to stop support for this methodology at the end of the year and so we're now in the process of upgrading our environment to work with Office 365 education. As such, we have set up and ADFS with an Azure AD but I'm struggling getting a process in place where our users still only need to enter their login credentials once on our portal (which is externally facing) and then providing them with a token that will persist on their trip to Office 365. Right now it works as follows: users go to portal.microsoftonline.com and enter their email address. When they tab out of that field, MS checks and finds our domain so then redirects the user back to a login page for our ADFS solution. At this point, users are required to log in again (if they're not already logged in) or they're taken to the MS offerings.
Bottom line, instead of making a "single" sign on solution, they've added more places that our users need to provide their credentials (or just username (email address)).
I'm wondering if there's a solution we can provide to our users similar to the SSO Toolkit 4.5 way of doing things where we can authenticate our users only once on our portal, then provide them access to the O365 services?
I'm not an infrastructure guy at all so I may have provided some misinformation above as to how we have things set up. What I do know from our current implementation is that we need to use "WS-Federation".
I'm wondering if a SAML approach would solve the issue I've described above and let us just challenge for credentials once on our portal page.
any ideas or suggestions would be greatly appreciated.
TIA
This is indeed possible. Read about AzureAD access panel (http://blogs.technet.com/b/ad/archive/2014/10/30/customize-your-app-sso-experience-with-azure-ad.aspx)
1) User will navigtate to https://myapps.microsoft.com/{your_school_domain_name.edu} 2) they will be directly redirected to your ADFS server for signin 3) once they signin they will see the list of apps assigned to them (including O365 apps) 4) click on OWA/SharePoint icon and navigate to the app without having to sign in again.
If you quickly want to test 1) and 2) open an in-private/cognito browser and navigate to https://myapps.microsoft.com/microsoft.com - you will not see O365 or Azure AD signing page - instead you'll be taken directly to the MSIT ADFS signin page.
Hope this helps.
All,
I am working on a SSO Project using WIF for my current employer .Registered users can log in to a portal that is public facing and receive access to a suite of applications . My employer has purchased a COTS Application(Claims Aware) hosted in another city . What they would like to do is the following
1a)Have Registered users log into the Portal located at portal.domain1.com
1b)During the login process , the portal communicates with an STS in the background which returns a signed and encrypted token back to the browser
2)User sees a link to the COTS Product on the Portal Page and clicks on it
3)They are redirected to app.domain2.com
4)App.domain2.com does not need to autenticate the user again since they receive the identity token from the portal .The user is able to establish a session from his browser with app.domain2.com
5)The browser is able to persist the token across all requests to the domain2 server
We will not be doing ADFS 2.0 but a Custom STS . My question is , is there a way to do it in SAML ?
Thanks,
Raja
You can push SAML authentication statements.
When the link is clicked on portal.domain1.com you use javascript to post a saml statement to app.domain2.com.
ADFS 2.0, WIF (WS-Federation): I want to implement SSO in the scenario when user goes to IdP web-site first to be authenticated. In this scenario our customers have intranet web-portals with links to our (service provider) web site, which actually lead them to IdP web site and redirect them to our web site as soon as user is authenticated. I could not find any info with technical details on how to implement it properly, can anybody?
What I did so far, I grabbed the redirection link to IdP using Fiddler to use as portal link and looks like it works, however I'm not sure if it's a proper way to do that. If you have similar experience please share.
UPDATE: More detailed use case: Our customer has its own intranet portal with link to our web site (service provider). The idea is to avoid additional initial http redirections and to have single entry point for different customers, so that our web site can count on security token coming from user to recognize identity of the customer, in other case we should have separate uri for any customer. User clicks the link, it leads him first to its own intranet IdP service (ADFS 2.0) that authenticates him with his windows account and adds security token and redirects him to our (relying party) web site where we can recognize him and his organization (customer) by the token, and he can consume our services. Let me know if something wrong or seems suspicious with the scenario.
Normal case is that the RP URL bound to ADFS via FedUtil is what ADFS return to. So if the portal is bound to ADFS (doesn't sound like it because you don't have to log in to get there?) then that's where you return when authenticated.
If your web site is what's bound to ADFS, then user goes to portal, clicks on link, gets authenticated, token with claims created and redirect to your web site.
I'm working on a proof of concept app. The basic functionality works, where I can log into one website, link to another site that shares the same STS, and the partner site picks up the credentials properly.
However, the partner site only requests the token if the page that we link to requires authentication (which kind of makes sense I guess).
Ideally, I'd like to link to a partner page that does not require you to be authenticated, BUT if the user IS already authenticated, I'd like to at least be able to recognize them on the partner site.
Currently, if my partner landing page does not require authentication, it doesn't appear that the user is logged in when they arrive. As soon as the user requests a page on the partner site that does require authentication, it then grabs the token without requiring the user to log in.
I've tried playing around with the SecurityTokenReceived and RedirectingToIdentityProvider events, but so far I'm stumped.
Any thoughts are appreciated.
So, the problem you are running up against is in dealing with the SessionAuthenticationModule hijacking the request. This module is responsible for detecting if the user has a valid session (based on a cookie that is written upon a successful redirect from the STS) and if not, to redirect the user to the STS to fetch a valid token. The WSFederationAuthenticationModule supplies the eventing necessary to hook into various stages of the redirection/authentication process.
Based on your description, it sounds like you want the following to happen:
User clicks on a link that redirects to the partner site
At the partner site, the request is intercepted and the system determines if the user is signed-in to the STS or anonymous
If the user has a valid session with the STS, then pull the claims for that user
The problem is, your RP cannot know that the user has a valid session without sending the user to the STS first (the RP's do not talk to each other or the STS. The user's brower is used as the means of communication between the RP's and the STS in the form of WS-Fed directives and SAML tokens passed in the url during redirects). If the user is sent to the STS, then they must authenticate, which could be a problem for anonymous users.
So, I do not think there is a "trick" that you can pull via configuration or interception of the request to determine if the user has a valid session with the STS. You might be able to pass a hint, however, from the referrer that is intercepted by the partner site. This hint could take the form of a parameter on the url that indicates to the partner site that the current user has a valid session and to go ahead and redirect to the STS (absence of this hint would indicate an anonymous user). You could also build a system to "hand-off" knowledge of the signed-in user using a resource that both sites have access to (i.e. database).
As you are sure to learn soon, more often than not, WIF offers pieces to the puzzle, but every situation is different and you have to supply the other pieces on your own.
Hope this helps!