Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
i want to derive role from SAML attributes like 'group' attributes.
my question is , if SAML identity provider would return all SAML attributes in SAML response ?
or i have to do something in SAML authentication request to ask for SAML attributes explicitly ?
thanks,
The identity provider and service provider need to agree on what information will be included in the SAML assertion. Typically this is done as part of setting up SSO between the two organizations and prior to any actual SSO. The identity provider needs to know what information you need so they can configure their system to include this information in the SAML assertion.
If there is certain information you need such as user group information then you need to specify this in your requirements to the identity provider. This is not done through the authentication request.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 11 months ago.
Improve this question
I have a django website and I'd like to allow students from a few universities to login to it using their university credentials.
I understand that I need to register with each of these universities first but what is that process like and what do I need to prepare on my end?
You have tagged SAML in you question so I will explain based on that. If you set up a integration with the universities using SAML, you will need to have software at your end to act as a SAML Service Provider(SP) and the universities will act as SAML Identiy Providers(IdP).
Tyipcal scenario.
When as student enters your site
User choose the university were they have an account.
User is redirected to the university login site with a SAML authentication request
User signs in to the usniversity login and is redirected back to you page with a SAML response, containing an SAML assertion.
The SAML assertion is the proof of authentication and you then validate this and let the user in to your site. The assertion also typically contain information about the user you can use in your application.
To set up this authentication, you will need a SAML SP software. A quick google suggest this might be something. You then need to contact the univerities and give them a metadata XML file from your software that tells them about your service. You also get a metadata XML from them that you import in your software to say that you trust them to authenticate users.
All this is ofcourse dependent on that the univerities want to allow you to use them to authenticate users.
You can ask your NREN. https://en.wikipedia.org/wiki/National_research_and_education_network
Usually a NREN will run a national federation which provides SSO for the research and education organizations such as the universities.
From your side you have to implement/install a working Service Provider, the easiest one IMO is the shibboleth Service Provider.
Then you ask your NREN to join the federation as a SP with your metadata (for shibboleth you can view your metadata at fqdn/Shibboleth.sso/Metadata). If you join the federation an your SP's metadata are published then the only thing that needs to be done by universities is to release the requested attributes to your service with an attribute-filter.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I have created a Cloud Firestore database, with a collection and some documents. I want to make some requests to it with Postman, but I am not able to authenticate. I have created a service credentials and tried to get the token for the authentication, with no success. Any idea about how to get it?
Which is the endpoint to get the token?
Thanks in advance.
Assuming you are trying to use Firestore REST API you can obtain token with the following steps:
Create a key for service account that you configured to access Firestore.
Open Cloud Shell, copy json with key info into it, and activate service account with gcloud auth activate-service-account --key-file=<path_to_json>
Print and copy its access token with gcloud auth print-access-token
Add Authorization header with value Bearer <copied_token> to your request or add it as a request parameter to url with ?access_token=<copied_token>
Keep in mind that these tokens are short-lived and are valid maximum for an hour.
For authenticating a user I am using keyCloak to get an access token. Some of the pages of application (ex: profile) needs to provide more information(User needs to answer some questions set by him earlier). Once the user's answers are validated, user should not be required to answer the questions again.
I am a beginner in JWT and keycloak. What is the best way to implement the above scenario?
As per my understanding, there should be 2 different tokens now, one will established that the user is authenticated for login and another will establish that user is authenticated for accessing profile page. If it's correct, how can I implement this in keycloak?
If not keycloak, what is the best way to implement this? I was reading the information available about keycloak but unable to get in a right direction.
If you want user to fill more info about him and to store this info at keycloak, you should consider implementing custom Required Action Spi. Also check out implementation of "Update Profile" required action.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Maybe this question seems opinion based, but I am facing a hard time in deciding to secure a RESTful API.
Firstly, my use-case:
My application is pretty straight forward: The front-end is written using React.js(for browser client) and that will consume the RESTful API for getting its data from the database(or something). The API is built using Spring framework.
This API is not a public API, and it has only a single client(as of now, later would be mobile apps).
Now lets come to the security problem. Obviously, I want to secure my API, I am using Spring-security as a tool for this job. During the starting days of learning, I knew only about the Basic-Authentication. But, when I kept on reading about more secure options, I learned some new fancy terms:
Token-based Authentication, using JWT
OAuth2
OpendId connect
When I read more blogs like from Auth0, Okta and a lot more, I messed up everything. This made me think twice if I should use OAuth for securing a REST API (which is not public). Also, almost all of the blogs about OAuth take examples of social logins. This made me more messed, that OAuth is for giving access of your API to the third party application. And that's it, not for my use-case.
I then asked some experts from some channels and blogs, some said the Basic-Authentication is very enough for security(using https) and I should avoid OAuth for such a small requirement. Other said opposite to that, saying Basic-Auth has security vulnerabilities.
Let's consider that OAuth is perfect for me, but in that case also, where would my Authorization server reside? Because tutorials only explain about Authorization server by keeping their code in the same layer. No separate project or something.
JWT also has some negative reviews for my user-case:
they cannot be revoked, will only expire on its own. Isn't it insecure?
they are massive in size, compared to session token or cookie
hight computational cost for verification
I really need some more advice on this, it has already taken my lot of weeks.
Thanks.
The real answer depends on information not in your question. For example do you need identity verification or are you just authorizing API access?
OAuth and Open ID Connect (OIDC) today are basically the same thing for most services such as Google Login. OIDC adds an identity layer on top of authorization. If you need to verify the identity of your users, log their activity, control resources per user, etc. this is your solution.
For authorizing API endpoints, there are many solutions. The most common are secret key value and JWT. Secret key has many weaknesses so I will not touch on that here.
A very common method of authorizing API endpoints is using JWT tokens and the Authorization: Bearer TOKEN HTTP header. I will now try to answer your concerns about using JWT tokens. Here I only refer to Signed-JWT tokens.
they cannot be revoked, will only expire on its own. Isn't it
insecure?
JWT tokens can be revoked by revoking the signing certificate. This would require creating a certificate revocation server, so this is not so common. An improved approach is to create short-lived tokens. Typical expiration time is 60 minutes (3600 seconds) but you can create tokens for any time period. When the token expires, the client requests a new one, which your backend can authorize or refuse.
they are massive in size, compared to session token or cookie
What is massive? You can create a token of any size from just a few bytes (the size of the signature plus data) or include extensive information in the token. Unless your tokens are out of control in size, this will not matter to most implementations.
high computational cost for verification
Again you are using a vague term. Verifying a Signed JWT is not computational expensive unless you are on tiny devices such as IoT (which are already using SSL certificates, encryption, etc.) or you need to handle millions of transactions per minute. In other words unless you have a solid reason to worry about CPU cycles, don't worry about them in regards to improved security.
Let's consider that OAuth is perfect for me, but in that case also,
where would my Authorization server reside?
Your OAuth 2.0 authorization server can reside anywhere you want. Implementing OAuth is very easy and there are many libraries to manage the details for you. Your authorization server can be part of your backend, be a separate server, etc. You can even just outsource this completely to identity providers such as Google Login, Auth0, Okta, etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In my understanding of SP-init and IDP-init SSO is as follow:
IDP-init SSO: A base64-encoded saml response is generated by IDP and send to SP, SP then verifies the response and finally the user is logged into the application if the response is valid.
SP-init SSO: A saml request is sent from SP to IDP, then IDP will authenticate the user then send back the saml response, the next part is same as IDP-init SSO.
How do we decide to choose whether the SSO is using SP-init or IDP-init ? SP-init seems to be more secure and reliable than IDP-init SSO because of the authentication part.
To me, the business requirements of the service provider's application tell you:
If all user interaction with the service provider's application will start at a "homepage", or default landing page, then IdP-initiated probably makes a lot of sense (less to break - no signed AuthnRequest needed).
If there are "deeplinks" that are provided to your users to things like reports via email (that is, a user can click on a link that should take them deep within the service provider's application), then SP-initiated is the only way forward.
In both instances, the user will be authenticated at the IdP based on the IdP's authentication rules - neither SP-init or IdP-init is "more secure" in that regard. The flows:
IdP-init:
User clicks link to start IdP-init SSO
IdP validates that User is authenticated - if not redirect for authentication
IdP converts authentication attributes (like username, email, etc.) into SAML assertion and redirects user to SP
SP converts SAML assertion to SP application token and redirects to application
SP-Init:
User clicks link to go to SP application
SP Application determines the user does not have a token and redirects to SP
SP redirects to IdP
IdP validates that User is authenticated - if not redirect for authentication
IdP converts authentication attributes (like username, email, etc.) into SAML assertion and redirects user to SP
SP converts SAML assertion to SP application token and redirects to application
The only difference, as you can see, is the first three steps.
You choose based on the desired or required navigation flow of a user (assuming browser POST binding based on your description).
If your requirements dictate the user start from secure (logged in) website A and navigate without password to site B, this is by definition IdP initiated.
If on the other hand the user is expected to be on an unauthenticated site yet log in with credentials from a partner site, this is where the SP initiated scenario comes into play. StackOverflow itself offers this style of sign in if you choose to log in with a Google account (though an alternative to SAML is used). The user starts somewhere on StackOverflow, clicks the login link, chooses their IdP (in SAML semantics) as Google, and are sent with an authn request to the IdP. After credential challenge of unspecified sort (eg your browser might already have an authenticated session at the IdP site, or the IdP might use two factor auth, etc) the user is returned to the SP site with a SAML response document.
SP-initialized is always to prefer. IDP-initilized will make work easier for the SP implementation but it comes with a buch of problems such as XSRF, interaoperability and deep linking.