Replies: 6 comments 4 replies
-
|
Any news on how to cleanly customise the AttributeStatement? |
Beta Was this translation helpful? Give feedback.
-
|
@convexset Thanks for your question. No plan to do it under v2 because it does require some refactoring work, I am still thinking if we can just simply expose a function allow the editing of response and keep the default response as simple as possible to fulfil the standard requirements. // Example after refactoring
const { response } = idp.createLoginResponse([arg1, [arg2, ...);
// Expose an instance function to customise the response before sending back to SP side
response.setAttributeStatement(opts); Feel free to comment on that. |
Beta Was this translation helpful? Give feedback.
-
|
What a tease |
Beta Was this translation helpful? Give feedback.
-
|
Mainly, there are two ways to initiate the single sign on, one is initiated by service provider (i.e. your app), another one is initiated by identity provider. It depends on your use case, but most of the application do support both initiation. The reason why we need service provider initiated sso is because we want to provide an entry point for each of our application, alongside with typical login methods (i.e. social media, or normal email/password). For identity provider initiation, we delegate the entry point to identity provider app, in other words, we don't have to provide a public login page application as the entry point. In fact, the flow for each initiation method is almost the same, the only major difference is that there is an extra step for service provider initiation. It requires to send a request to identity provider, and then the flow is the same as identity provider initiation. Let's go through it step by step on how to complete setup of IdP, let make a base configuration const baseConfig = {
privateKey: readFileSync($privateKey), // in .pem format
metadata: readFileSync($metadata); // metadata in xml format
privateKeyPass: 'q9ALNhGT5EhfcRmp8Pg7e9zTQeP2x1bW' // optional if your key file is not protected
};Lines 1 to 35 in b422c21 This is the simplest configuration that required to construct an identity provider instance. The private key is used to sign SAML document, and NEVER EXPOSE IT TO PUBLIC DOMAIN. The service provider will take idp's public key put inside the exchanged metadata to verify the signature. import { IdentityProvider } from 'samlify';
const idp = new IdentityProvider(baseConfig);We will go through more complicated configuration in the later chapter, now let's create a simple IdP service using express. import express from 'express';
const app = express();
app.listen(5000, () =>
console.log('My idp is listening on port 5000'),
); SP-init: Create an endpoint for service provider to send login requestIf your application supports service provider initiated SSO, your target identity provider has to provide an endpoint to accept the request. The protocol binding can be either redirect (GET/) or post (POST/), the endpoint is also needed to specify in idp's metadata as a contract. Lines 29 to 31 in b422c21 So now let's just simply create an endpoint (POST/ /sso/SingleSignOnService) app.post('/sso/SingleSignOnService/:id', async (req, res) => {
const { extract } = await idp.parseLoginRequest(sp, 'post', { body: { SAMLRequest }});
// extract is an object contains the default parsed result
// i.e. extract.issuer, extract.nameIDPolicy, ... etc
// cache your request id somewhere in your storage
// return to the login page, the GET /idp/login controller will check the session existence
return res.redirect('/idp/login?request_id=xxx');
});By using
// Create an endpoint for accepting the login credentials
app.post('/idp/login', async (req, res) => {
// verify the password login is the business logic of idp
// this library is not serving for the integration
// after the login credentials are successfully verified
const requestId = req.body.requestId;
const info = { extract: { request: { id: requestId }}};
const { id, context: SAMLResponse } = await idp.createLoginResponse(sp, info, 'post', user);
// destruct the context and send it back to the service provider
// return the response context back to frontend page
// the frontend page will do another form post sending response back to service provider to
// complete the whole SSO process
return res.render("autores", essentials);
});You can choose your view engine to render the response context in the frontend page and use script to do an automatic form post. Or you can redirect with a simple html page in string. The essentials include samlify/examples/metadata/metadata_sp1.xml Lines 45 to 46 in 160583b return res.send(`
<html>
<body>
<form id="sso" method="post" action="${spAcsUrl}" autocomplete="off">
<input type="hidden" name="SAMLResponse" id="resp" value="${SAMLResponse}" />
</form>
<script type="javascript">
document.forms[0].submit();
</script>
</body>
</html>
`);After that, identity provider side finishes its job, to send back the SAML response. At this stage, a session is already established between user and identity provider, it suppose that it won't redirect back to the IdP login page unless the session is expired. The service provider will handle another session between IdP and itself. |
Beta Was this translation helpful? Give feedback.
-
|
Great writeup, thank you! I have a question though...I apologize if this isn't the correct place. I am working on an implementation in an app to interface with an external SP. The SP does not care about the implementation of the IdP whatsoever. There would never be an instance where the SP would redirect back to us for login, or initiate the login. We actually have a (very bad) working implementation in .NET that generates a SAML Response, signs the assertion, and encodes the response in Base64 and triggers a browser redirect like your example. We are trying to replace this. We don't really rely on the SP metadata file as we build the SAML Response/Assertion completely from scratch in our current implementation. However the SP does provide the metadata file, the cert with the private key to sign the assertion (I know, I know... but this is their implementation/requirements), and the ACS endpoint. We initiate the redirect to the SP always, after a user is already logged into our app. So, for example, a logged in user clicks a link to the SP, which triggers the building of the SAML Response, the signing of the assertion, the base 64 encode, and returning the HTML document (similar to above) which triggers the redirects to the SP. Is it possible to adapt the above to fit out needs? We don't have any IdP defined metadata because the SP doesn't care about our implementation. We would also most likely use a template to define attributes on the assertion. Kind regards and thanks in advance! |
Beta Was this translation helpful? Give feedback.
-
|
@joshuajbrunner Yes, your use case is just IDP initiated SSO, right ? For IDP initiated SSO, you will just need to generate the SAML response based on the user login, then do a form post back to the ACS endpoint that SP provides. |
Beta Was this translation helpful? Give feedback.
-
|
@tngan Sorry if it's not correct place, I get a error when try to Login via SSO (Post) . Can you help me through? |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, I'm seeking assistance with a project I'm working on, and I hope someone can point me in the right direction. I'm currently building a course on the website edApp.com, which supports organizational sign-ups using SAML. My goal is to create a sign-up portal using Firebase that acts as an Identity Provider (IdP) for edApp. This would allow our users to sign up through our portal and then be redirected to edApp seamlessly. I'm wondering if this aligns with any use cases you've encountered before. Specifically, I'm interested in whether it's feasible to construct our own IdP using Firebase, React, and SAMLfy to address this challenge. Any guidance or insights you can provide would be greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
@mudebbela Firebase SDK (SAMLAuthProvider) should handle the IDP side for you. (https://firebase.google.com/docs/auth/web/saml) |
Beta Was this translation helpful? Give feedback.
-
|
I've spent a week on this and am really confused.. How do i set up an IDP (for IDP initiated login), when I don't have the SP XML metadata? The SP just provides the ACS url, and I provide my certificate SHA1 fingerprint. That's all there is to setup, however I can't figure out how to implement this with this library |
Beta Was this translation helpful? Give feedback.
-
This is the official guidance on how to create a simple identity provider by using samlify.
Charged IdP usually has a lot of features in application level, this library only provides simple functions that allows you to construct the flow with request/response parser, and help you to extract essential information from those complicated and "human unreadable" XML.
There are so many questions related to build an IdP for testing purpose upon these few years, so we decide to provide coding tutorials for constructing a simple IdP.
Beta Was this translation helpful? Give feedback.
All reactions