We are running a website where users need to be authenticated from the SAP Enterprise Portal.
Scenario:
User logs in into SAP portal via SAML Authentication. This user can view a link in the Portal he can click the link and will be transferred to a website on another domain. This domain will receive the a "ticket" and the user will be able to login.
Information from a friend:
If you have a setup that uses SAML, there are mechanisms to transfer that session between domains that basically rely on passing a ticket through the URL to the client from the authentication server, and that ticket is then passed to the site you want to authenticate against, which can use that to establish the identity of the user with the authentication server and establish the session.
Question:
Is this possible in SAP? If so, can anyone provide me some documentation for this?
The normal scenarion for SSO between domain in SAML is based on relayance on the same IDP. This is a typical flow for a SSO with two domains.
Sign-on on domain1
User accesses domain1
User is forwarded to IDP for authentication.
User authenticates and a session is created at the IDP
User is redirected back to domain1 and gains access
Sign-on on domain2
User accesses domain2
User is forwarded to IDP for authentication.
The IDP already as a session for the user and is considered as authenticated
User is redirected back to domain2 and gains access
This way the uer does not need to authenticate the second time.
Related
How can I authenticate multiple applications with a single authentication mechanism?. These applications are having existing authentication within them, perhaps I need to authenticate these apps into my system which is isolated from others. Please suggest a better approach
When using OpenID Connect, the first application the user logs in to, will redirect the user's browser to the authorization server (AS). Since the user does not have a session between the browser and the AS, it will present the login screen. The user signs in and is redirected to the application (client) with an ID token and access token. The application will then establish a session between the browser and the application (typically a cookie)
When the user navigates to the second application, it will also redirect the user to the AS, but now the user already has a valid session between the browser and the AS, so the AS won't show the login screen (it may show the consent screen if the user has not consented to the requested scopes), and will issue an ID token and access token to the second application.
Now the user has a authenticated session with both applications with a single sign on (SSO).
If you use OAuth 2.0 with OIDC, you can authenticate your user once and verify the access token at each app the user visits. This is a typical single sign-on flow (SSO).
Background:
I have a basic user database with username(email) and password. The users are able to sign in to a website of mine with these credentials. From the website they get a link to different services they have access to, but with different username/passwords. So they click the link "Open My Service X" and they have to login with their service unique login credentials. I do have the users service login-username. So I can map local-user <=> service-user.
I want SSO between service X which has support for SAML and my website.
Question/Problem:
I want the users to login with their user/password in my database, then single sign on towards service X where service X has support for SAML. I don't want a user to be able to sign up for a new user account to my website using the SAML support in service X. The user must already have an account in my database.
So my question might be rather vague, but I'm having a hard time to grasp how this can be achieved?
I was thinking of letting my webapp become a SAML identity provider, so that the SSO request are transferred back to my webapp and verified for their service-user. Would that be correct approach?
You're on the right track with your SAML IdP. There are basically three parts involved. Your email database (the identities), your existing application front end and the remote services which support SAML. Usually it's SAML2 these days.
To get single sign-on (SSO) across your portfolio of apps (your own app and the remote services) you could install an IdP like the Shibboleth IdP and convert your app to use it instead of using email/password to login. That would take a fair amount of work as you'd have to convert your app into a SAML SP, just like the remote services.
An easier way might be to only use the IdP for SAML to the remote services and get the IdP to recognise that your users are already logged in with their email/password. Cookie? So the IdP should never display a login page as it would recognise your app's cookie and match that with a user in the database. It then releases SAML attributes to the remote service based on that user's information. That also covers your use case of not allowing account creation via SAML from a remote service.
That would mean you might end up with the following URLs:
https://yourapp.com/
https://yourapp.com/idp/
Your users login with the first URL as normal and the remote services use the second URL. That way your app cookie will be visible to the /idp endpoint but you'd need to write code to match that with a user in the database.
I need to restrict access to an external site so that:
users who are in the corporate network have full access to the site's functionality,
those who are not - only limited functionality.
In the corporate network users do authenticate against a windows domain. In the network I can set up a server/service which can do the identity verification. This is secure, I have no doubt, especially when it is inside.
The external site is not a part of the domain.
What I suggest to myself is to setup a service, which will authenticated users against, create a secure token and then re-direct users to the external site. So that users will authenticate there without entering password (maybe not even login).
I'm in doubt: how this can be done? How secure this can be? How much heavy/crypto development are there?
I assume that the secure token should be time-bounded, that both external site and internal auth service should support SSL/TLS (symmetric/asymmetric keys?).
Am I missing something here? Surely, I am, but what?
Make the external site a SAML 2.0 Service Provider (SP).
Set up an internal SAML 2.0 Identity Provider (IdP) to authenticate the corporate users with SAML 2.0 ADFS. Use SP initiated SSO and have the external site configured to hand off to your IdP with HTTP-POST.
The IdP can be configured to authenticate a user logged into your ActiveDirectory domain with a browser capable of NTLM transparently. It should just authenticate them and sign an assertion to that effect and redirect them back to the external site. If they don't have NTLM they'll be promtped for their domain credentials first.
UPDATE: as noted by #Steve the external site still needs to authenticate external users. Making your external site a SAML SP doesn't solve that. You could have the external website do some built-in authentication or you could have a different SP endpoint (URL) for external users and use another IdP for them.
Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.
I am wondering how CAS works (workflow needed). Imagine:
User authenticate with CAS on App1 (example.com/app1, for example).
User goes to another application (example.com/app2).
Every application must show user's name on top of the page. How they know it? In case of just ONE application, the workflow is pretty clear:
App1: While user browse pages without authentication, just show "Login" link as user name.
App1: At one moment user presses Login.
App1: Redirects user to CAS
CAS: Requests user's login/pass
CAS: User enters login/pass
CAS: Redirects user back to App1
App1: gets token and user name (or ID) from CAS, and gives some rights to this user.
Done.
But now: how the App2 (App3 and so on) knows that user is already authenticated? Do they all have to redirect user from EVERY page to CAS just only to know, if the user already authenticated and request his name?
In case of Spring it will be a huge redirections, while I have some independent applications like:
example.com/App1
example.com/App2
...
example.com/AppN
I don't have have 10 reputation yet, so you will need to check the workflow image at
http://idms.rutgers.edu/cas/how_does_it_work.shtml
When a new user initially logs into an application they won't have established a session with the application. Instead of displaying a login form asking for the username and password, the application (via the CAS Client) will redirect the browser to the CAS login page.
CAS then authenticates the user. If the authentication fails, the CAS login page is displayed again with an error message. So until authentication succeeds, the user will not be returned to the application. If the user is not sure how to proceed at that point, there are help desk links on the CAS login page. Once the user authenticates successfully, CAS will redirect the browser back to your application. CAS knows where to redirect to via a {service} parameter that you append to the CAS login url.
When CAS redirects the authenticated user back to your application, it will append a {ticket} parameter to your url.
The ticket returned to your application is opaque, meaning that it includes no useful information to anyone other than the CAS Server. The only thing that your application can do is send this ticket back to CAS for validation.
CAS will then either respond that this ticket does not represent a valid user for this service, or will acknowledge that this ticket proves authentication. In the later case, CAS will also supply the username so that you know the identity of the user.
The application must provide its own session management. Once the user is authenticated, your application should keep track of this fact within a session so that you don't have to reauthenticate them with the CAS Server. Typically this would be the same as if you authenticated the user directly from your application.
Each application should provide their own logout facility which will invalidate the session and require the user to re-authenticate into the application. Note that if they are using SSO through the myRutgers portal, they will not have to re-enter their username and password.
Using CAS means, that the CAS-Server keeps track of which user is authenticated globally (using a cookie which stores a Ticket Granting Ticket Id - TGT). Each application must maintain its own mechanism to key track of a principal session and the corresponding information.
So if a user wants to access a secured application APP1 (and is not authenticated), he will be redirected to the CAS-Server. Without sending a valid TGT the login-form is presented, otherwise (or after successfully authenticating to the CAS-Server) a Service Ticket (ST) is generated, which must be presented to APP1. Here this Service Ticket is validated against the CAS-Server (using server-to-server communication) - if valid, the userId (and perhaps additional information) is returned.
Now it's up to the application APP1 to create a principal based on the userId and to provide authorization information (e.g. the CAS-Server authenticates against an LDAP, whereas APP1 stores the user data in a database).
All subsequent requests to APP1 should not involve the CAS-Server anymore.
If the user makes a request to APP2, the mentioned process restarts again.
L'sync,
Have you tried posting your question to the cas-users [cas-user#lists.jasig.org] mailing list?
I have been working with CAS for the last 6 months and from what I understand, App2 (App3 and so on), without redirection to CAS do not have a way of knowing the user-attributes.
You can avoid putting all pages of App2 behind the CAS filter by either storing the user-attributes along with your web-session and/or by embedding an iframe-header in your pages which displays the login-name.
Marvin who is a CAS contributor maintains an excellent CAS client test webapp on GitHub where you can see how he reads the user-attributes.
https://github.com/serac/java-cas-client-test